الأمن السيبراني

من الاستدلال بالتوقيعات إلى الذكاء الوكيلي: كيف يتغير تصميم أنظمة كشف التسلل

يحلل المقال دور SnortML في توسيع قدرات Snort 3 لاكتشاف نسخ جديدة من هجمات معروفة، ويقارن ذلك بالذكاء الاصطناعي الوكيلي الذي يضيف السياق الزمني والتحقيق متعدد المصادر. كما يناقش حدود النهج الحالي، وبنية التكامل المقترحة، ومتطلبات النشر الآمن.

06 يوليو 2026
7 دقائق قراءة
0 قراءة
من الاستدلال بالتوقيعات إلى الذكاء الوكيلي: كيف يتغير تصميم أنظمة كشف التسلل

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

لا تكمن مشكلة التوقيعات التقليدية في أنها غير دقيقة، بل في أنها دقيقة تجاه ما صُممت لاكتشافه. فقاعدة مخصصة لثغرة بعينها مثل CVE-2024-12345 قد تلتقط الاستغلال المعروف مع معدل منخفض جداً من الإنذارات الكاذبة، لكنها قد لا تستجيب لحمولة معدلة تمر عبر المسار البرمجي الضعيف نفسه. وبين ظهور استغلال جديد في البرية وتحليله وكتابة قاعدة له واختبارها وتوزيعها، قد تمر أيام أو أسابيع، وهي فجوة خطرة عندما تكون الثغرة مستغلة فعلياً.

كيف يعمل SnortML داخل Snort 3؟

قدمت Cisco Talos محرك SnortML في مارس 2024 بوصفه محرك كشف للتعلم الآلي يعمل أصلاً داخل Snort 3. ولا يعتمد المحرك على خدمة سحابية خارجية، إذ يجري الاستدلال محلياً ضمن مسار المعالجة نفسه المستخدم لتقييم القواعد، ويصدر نتيجة خلال أقل من ميلي ثانية.

يتكون التنفيذ من وحدة snort_ml_engine التي تحمل نماذج TensorFlow المدربة مسبقاً عند بدء التشغيل، ومفتش snort_ml الذي يستقبل البيانات من مفتشات الخدمات القائمة في Snort 3 عبر واجهة النشر والاشتراك. فعندما ينتهي مفتش HTTP من تحليل الطلب، يرسل سلسلة الاستعلام ومحتوى POST إلى ناقل الأحداث، ثم يصنفها SnortML ويعيد قيمة احتمالية تشير إلى احتمال احتوائها على محاولة استغلال.

يعتمد النموذج على شبكة LSTM تسبقها طبقة تضمين تحول قيم البايتات الخام إلى تمثيلات متجهية، ما يسمح بالتقاط العلاقات والسياق بين البايتات، قبل أن تعالج LSTM ترتيبها وتسلسلها. وتختزل طبقة كثيفة نهائية النتيجة إلى قيمة احتمالية واحدة. ويستخدم LibML، المرفق مع SnortML، مكتبة XNNPACK لتسريع عمليات المصفوفات. ووفق المادة، تستغرق عملية تصنيف واحدة نحو 350 ميكروثانية على معالج AMD بتردد 4.7 غيغاهرتز.

ومن Secure Firewall 10.0.0 فصاعداً، يختار SnortML تلقائياً نموذجاً مناسباً لأطوال 256 أو 512 أو 1024 بايت. أما الطلبات التي تتجاوز 1024 بايت فتُقتطع عند هذا الحد قبل التصنيف. بدأ الإصدار الأول بكشف حقن SQL، ثم توسعت التغطية حتى أواخر 2025 لتشمل XSS وحقن الأوامر، وتصل تحديثات النماذج عبر نظام Lightweight Security Package نفسه المستخدم لتوزيع محتوى القواعد.

قوة النهج الهجين وحدوده

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

لكن SnortML يحلل معلمة HTTP منفردة، مثل سلسلة استعلام URI أو محتوى POST، ولا يعرف ما حدث قبل الطلب أو بعده أو ما فعله عنوان المصدر خلال الدقائق السابقة. لذلك قد تمر سلسلة استطلاع ثم تعداد ثم استغلال مخصص من دون أن تتجاوز أي خطوة منفردة عتبة الكشف. كما أن النموذج الحالي لا يرى أنفاق DNS أو هجمات طبقة TLS أو استغلال SMB أو السلوكيات الشاذة في البروتوكولات غير HTTP، لأن النماذج المتاحة مرتبطة بمسار بيانات مفتش HTTP.

ويضيف زمن المعالجة البالغ نحو 350 ميكروثانية كلفة حقيقية، وإن كانت محدودة ومتوقعة بفضل XNNPACK. لذلك لا ينبغي النظر إلى أداء النموذج بمعزل عن حجم مجموعة القواعد وتعقيد البروتوكولات وميزانية المعالجة في جهاز الحماية.

ما الذي يضيفه الذكاء الاصطناعي الوكيلي؟

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

ويشير المقال إلى إطلاق IBM لمنصة ATOM، أو Autonomous Threat Operations Machine، في أبريل 2025، وإطلاق Trend Micro لـ Agentic SIEM في أغسطس 2025. وتُعرض هذه الأنظمة كمنصات تنسيق وتحقيق متعددة الوكلاء، لا كواجهات محادثة مزودة بمعلومات أمنية فحسب. ويربط التحليل انتشارها بضغط نقص الكوادر؛ إذ يذكر فجوة عالمية تقارب أربعة ملايين وظيفة شاغرة في الأمن السيبراني، إلى جانب استطلاع في 2025 أفاد بأن 82% من محللي مراكز العمليات الأمنية يشعرون بالقلق من تفويت تهديدات حقيقية بسبب حجم التنبيهات.

في هذه البنية، يصبح Snort 3 وSnortML مستشعرين قريبين من الشبكة، يقدمان ما تمت ملاحظته فعلياً إلى طبقة الاستدلال الأعلى. لكن ارتفاع مستوى الأتمتة يجعل دقة المستشعر أكثر أهمية: فالإنذار الكاذب لا يستهلك وقت المحلل فقط، بل يستهلك موارد الوكلاء وقد يطلق إجراءات احتواء في بيئات سيئة الضبط. كما تسمح النتيجة الاحتمالية لـ SnortML ببناء درجة ثقة مركبة؛ فتنبيه يجمع توقيعاً تقليدياً ودرجة ML تبلغ 0.97 يجب أن يعامل بطريقة مختلفة عن تنبيه أطلقه ML وحده بدرجة 0.61.

بنية التكامل ومشكلة حلقة التغذية الراجعة

يقترح المقال بنية تبدأ بطبقة التقاط الحزم عبر DAQ، باستخدام AFPacket RSS أو DPDK وفق متطلبات الإنتاجية، ثم طبقة كشف تشغل محرك MPSE Hyperscan وSnortML بالتوازي. وترسل الطبقتان أحداثاً بصيغة JSON تتضمن التنبيهات ودرجات الاحتمال وبيانات التدفقات إلى ناقل قياس موحد.

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

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

قيود النشر والتوصيات العملية

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

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

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

من نفس التصنيف

مقالات قد تهمك

عرض جميع المقالات