Reco خفّضت زمن الاستجابة للحوادث بنسبة 63% باستخدام Amazon Bedrock

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

لماذا تُبطئ التنبيهات العمل

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

كانت لدى Reco مهمتان تطبيقيتان: الأولى أن يفهم المحلل معنى التنبيه دون فك تشفير يدوي مطوّل للحقول والعلاقات بينها. والثانية ألا يقتصر النظام على ملخص موجز، بل يقترح فورًا كيفية المضي في التحقيق والخطوات اللازمة بعد ذلك. ويُعدّ هذا بالغ الأهمية لمركز عمليات الأمان (SOC): إذ ثمة فرق شاسع بين رصد تسجيل دخول مشبوه أو سلوك مستخدم شاذ، وبين الفهم السريع للضرر المحتمل وأولوية الحادث والخطوات الملموسة للتحقق من المخاطر والتخفيف منها.

كيف يعمل المولّد

لمعالجة هذه المهمة، تستخدم Reco نظام Alert Story Generator المدعوم بـ Anthropic Claude في Amazon Bedrock. يأخذ النظام تنبيهًا محددًا، ويسترجع بياناته الوصفية وأمثلة من تحليلات سابقة، ثم يُجمّع prompt سياقيًا. وقد أدّى التحول من نهج zero-shot إلى نهج few-shot دورًا محوريًا: إذ حسّنت أمثلة المرجع المختارة بعناية استقرار استجابات النموذج وبنيتها تحسينًا ملحوظًا. علاوةً على ذلك، تختار Reco الأمثلة ديناميكيًا بحسب مصدر التنبيه ونوعه، لكي يعتمد النموذج على سيناريوهات ذات صلة لا على قالب عام.

• تحويل JSON الخام إلى وصف موجز ومفهوم
• إبراز المخاطر الرئيسية والأضرار المحتملة وأولوية الاستجابة
• توليد استعلامات تحقيق جاهزة للاستخدام
• إعداد ملخص مفهوم لكل من فريق الأمان وأصحاب المصلحة من الناحية التجارية
• توليد توصيات التخفيف من المخاطر دون تجميع يدوي للخطوات

يسير خط الأنابيب الذي يعقب ذلك بشكل مباشر: يختار المستخدم تنبيهًا في الواجهة، فيسترجع النظام JSON من قاعدة البيانات ويجمعه مع أمثلة few-shot والأمثلة المعروفة بـ golden examples، ثم يرسل الطلب إلى Claude Sonnet عبر Amazon Bedrock. تُعاد الاستجابة إلى العميل على هيئة تفسير جاهز وقائمة إجراءات. يُنشَر النظام بأكمله على AWS: تعمل الخدمات المصغّرة على Amazon EKS، وتُخزَّن البيانات السياقية في Amazon RDS for PostgreSQL، ويحمي AWS WAF الوصول إلى الواجهة، بينما يُسرّع Amazon CloudFront التسليم. وتستخدم Reco بصورة منفصلة Bedrock prompt caching، مما أسهم في خفض زمن استجابة الاستدلال بنسبة 75%.

ما الذي تغيّر بالنسبة لـ SOC

الأهم في هذه الحالة هو الأثر القابل للقياس، لا مجرد واجهة جميلة فوق LLM. وفقًا لبيانات Reco، تحسّن وقت التحقيق بنسبة 54%، لأن المحللين لم يعودوا بحاجة إلى بناء استعلامات من الصفر وتفسير كل حقل في التنبيه يدويًا. وانخفض وقت الاستجابة للحوادث بنسبة 63%: إذ يقترح النظام فورًا توصيات مرتّبة حسب الأولوية يمكن اعتمادها مباشرةً دون تحضير مطوّل مسبق. ويظهر هذا جليًا في الخط الأول من الدعم، حيث كان كثير من الحالات يُحال سابقًا بسرعة إلى متخصصين أكثر تكلفةً وأشد ندرةً.

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

ما الذي يعنيه هذا

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