الركيزة الثانية لجاهزية تهديدات الذكاء الاصطناعي: تسريع عملية التصحيح والاستجابة

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

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

في هذه التدوينة نتعمق في الركيزة الثانية لإطار الاستعداد لتهديدات الذكاء الاصطناعي: تسريع عمليات التصحيح والاستجابة.

لماذا يعد تسريع التصحيح والاستجابة أمرًا بالغ الأهمية للاستعداد لتهديدات الذكاء الاصطناعي

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

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

• ملكية غير واضحة: تكتشف فرق الأمان الثغرة الأمنية، لكنها غالبًا لا تعرف من أرسل التعليمات البرمجية، أو من يملك المورد المتأثر، أو من يمكنه إصلاحها بالفعل. يمكن أن تستغرق عملية التوجيه وحدها وقتًا أطول من الإصلاح نفسه.

• إرشادات العلاج العامة: يخبرك تحذير CVE بوجود ثغرة أمنية والإصدار الذي تريد الترقية إليه. ولا يخبرك ما إذا كنت تريد تصحيح المثيل قيد التشغيل، أو تحديث الصورة الأساسية، أو إصلاح ملف Dockerfile، أو تغيير قالب Terraform. وبدون سياق خاص بالبيئة، تضيع الفرق الوقت في اكتشاف مسار الإصلاح الصحيح.

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

هذه ليست مشاكل جديدة، لكن الذكاء الاصطناعي جعلها ملحة. تدور الركيزة الثانية حول حل المشكلات الثلاثة.

أهداف هذه الركيزة هي:

• يٌرسّخ واضح ملكية ومن ثم يتم توجيه النتائج إلى الفريق المناسب تلقائيًا.

• تعريف ال جذر سبب لكل ثغرة أمنية – سواء كانت تهيئة خاطئة، أو تبعية قديمة، أو خلل على مستوى التعليمات البرمجية.

• يحدد ال أفضل يصلح طريق استنادًا إلى البنية المحددة لبيئتك، بدءًا من التكوين السحابي وحتى التعليمات البرمجية المصدر.

• أتمتة علاج سير العمل للتخلص من الفرز اليدوي وتقليل متوسط ​​الوقت اللازم للمعالجة.

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

كيف يدعم Wiz الركيزة 2: تسريع عملية التصحيح والاستجابة

تسريع الاستجابة من خلال الملكية الموحدة

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

يبني Wiz نموذج ملكية موحدًا من كل مصدر تستخدمه مؤسستك بالفعل، سواء داخل Wiz أو متصل به:

• خدمة ملكية: احصل على خدمات محددة من Wiz Service Catalog، الذي يكتشف الخدمات تلقائيًا، أو انسحب من تكامل Backstage الخاص بك. تكتسب الموارد في Wiz الملكية تلقائيًا من الخدمة التي تنتمي إليها.

• مشروع ملكية: قم بتجميع الموارد حسب وحدة العمل أو التطبيق أو البيئة مع المالكين المعينين في Wiz أو قم بالمزامنة من ServiceNow CMDB لتعبئتها تلقائيًا. يتم تحديد نطاق المشكلات للفريق المناسب بناءً على المشروع الذي تؤثر عليه.

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

• على أساس التعليمات البرمجية ملكية: استفد من ملفات CODEOWNERS لتحديد من يملك مسارات تعليمات برمجية محددة، وGit Blame لإسناد النتائج إلى المطور الذي قام آخر مرة بتعديل الخط المتأثر، وتعيين التعليمات البرمجية للسحابة من Wiz لتتبع الموارد المنشورة مرة أخرى إلى المصدر. يمكن ربط النتائج مباشرة بالمطور المسؤول عن الكود الذي قدمها.

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

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

إريك تو، مهندس أمن المنتجات، Rogo AI

ولأتمتة مهام سير العمل على نطاق واسع، تكون مهام سير العمل بجانبك باستخدام قالب تعيين الملكية المدمج لتوجيه المشكلات الحرجة تلقائيًا إلى المالك المناسب.

قم بالمعالجة عند المصدر مع Green Agent

عندما يتم العثور على ثغرة أمنية حرجة، نادرًا ما يكون السؤال الأول هو “ما هو برنامج مكافحة التطرف العنيف؟”، بل “أين يمكنني إصلاح هذا بالفعل؟” ربما يتم تشغيل حزمة ضعيفة على جهاز افتراضي، ولكن قد يكون الإصلاح الحقيقي في صورة الحاوية، أو ملف Dockerfile، أو التبعية المعلن عنها بثلاث طبقات في وحدة Terraform.

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

يقوم Green Agent بتجميع المعلومات من جميع أنحاء منصة Wiz – بيانات تعريف الموارد، والتكوينات السحابية، وسياسات الهوية والوصول، والتعرض للشبكة، ومعلومات الملكية من الرسم البياني وعمليات التكامل، ومسار التعليمات البرمجية إلى السحابة – لتقييم مسارات المعالجة المتعددة والتوصية بالاستراتيجية الأكثر كفاءة.

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

ومن أجل التنسيق على نطاق أوسع، يمكن للفرق توجيه المعالجة من خلال سير العمل لتخصيص استجابتهم بناءً على ما هو منطقي لمؤسستهم.

قم بقياس الاستجابة بسرعة الآلة باستخدام سير عمل Wiz

يوفر Wiz Workflows طبقة التنسيق للفرق لأتمتة سلسلة المعالجة الكاملة – بدءًا من التحقيق وحتى تعيين الملكية وحتى إشعار المطور – من خلال لوحة السحب والإفلات القابلة للتكرار والتخصيص.

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

من خلال الجمع بين إجراءات النظام الأساسي ووكلاء الذكاء الاصطناعي وعمليات التكامل مع أدواتك الحالية من خلال النظام البيئي لشبكة Wiz Integration Network (WIN)، يمكن للمؤسسات إنشاء عمليات معالجة قابلة للتكرار تعمل على تقليل التعرض بشكل مستمر وتسريع أوقات الاستجابة.

منع التكرار عن طريق التحول إلى اليسار

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

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

تمتد حواجز الحماية هذه إلى أقصى اليسار باستخدام مكونات Wiz Code الإضافية، والتي تجلب نفس سياسة التنفيذ مباشرة إلى IDE الخاص بالمطور في شكل Wiz Skills وWiz Hooks. تقوم المكونات الإضافية بالمسح في مرحلة ما قبل الالتزام والدفع المسبق بحثًا عن الأسرار وتكوينات IaC الخاطئة والتبعيات الضعيفة، مما يضمن بقاء بوابات الأمان ثابتة سواء كان الإنسان أو وكيل الذكاء الاصطناعي هو من يكتب الكود.

ويرفع WizOS خط الأساس بشكل أكبر، مما يوفر صورًا معززة للحاويات تزيل نقاط الضعف الموروثة قبل كتابة سطر واحد من تعليمات التطبيق البرمجية، وتحافظ على سلامة سلسلة التوريد، وتتضمن اتفاقيات مستوى الخدمة لمعالجة CVE. عندما يتم العثور على CVEs في الحاويات، يتبعك Green Agent هناك أيضًا، ويوصي بصورة WizOS المحددة للانتقال إليها، ويمكن للفرق إرسالها مباشرة إلى وكيل الترميز لتطبيق المبادلة. يبدأ المطورون بشكل آمن افتراضيًا، مما يقلل من حجم النتائج التي يجب فرزها في المراحل النهائية.

خطوات عملية للتنفيذ اليوم

• يتصل لك ملكية مصادر بما في ذلك ملفات CODEOWNERS ومستودعات التعليمات البرمجية والبيئات السحابية وعمليات تكامل CMDB/Backstage حتى يتمكن Wiz من اقتراح المكلف المناسب تلقائيًا عند ظهور المشكلات.

• يُمكَِن أخضر عامل لتحليل أهم المشكلات الحرجة والعالية تلقائيًا من خلال إرشادات المعالجة الخاصة بالبيئة والمالكين المقترحين.

• يبني لك أولاً سير العمل لأتمتة عملية معالجة كبيرة الحجم، ابدأ باستخدام قالب تعيين الملكية لتوجيه المشكلات الهامة تلقائيًا.

• نشر الحذق شفرة الإضافات و ويزو لتحويل حواجز الحماية إلى اليسار ومنع نشر المخاطر في المقام الأول.

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

تحقق من مدونتنا التالية في هذه السلسلة للتعرف عليها الركيزة 3: إجراء تحليل كود الذكاء الاصطناعي محليًا في Wiz.

مستعد ل يحصل بدأت؟ جدولة العرض التوضيحي.