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

يستكشف Larry Maccherone العديد من المزايا لإضافة الأمان إلى DevOps


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

في هذه الجلسة الرئيسية المؤرشفة، يسلط Larry Maccherone، مهندس تحويل DevSecOps لشركة Contrast Security، الضوء على طرق تحويل عملية AppSec وDevOps بشكل أساسي، إلى نهج DevSecOps الحديث. كان هذا الجزء جزءًا من ندوتنا المباشرة عبر الويب بعنوان “كيفية تضخيم DevOps باستخدام DevSecOps.” تم تقديم هذا الحدث بواسطة InformationWeek في 22 مايو 2024.

نسخة من الفيديو يلي أدناه. تم إجراء تعديلات طفيفة من أجل الوضوح.

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

لا يزال لديهم العقليات التي تتوافق مع هذه العقلية، مثل حراسة البوابة. إذا كان لديك فريق يتابع DevOps، فمن المستحيل أن يتم إصداره عدة مرات يوميًا للإنتاج.

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

متعلق ب:التطبيقات التي لا تحتاج إلى تعليمات برمجية أو تستخدم تعليمات برمجية منخفضة: انظر قبل أن تقفز

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

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

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

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

متعلق ب:هل يمكن للمطورين لديك الاستفادة من هندسة المنصات؟

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

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

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

وكل هذه الأمور جيدة تقريباً، لكنها ليست كافية لحل المشكلة. لدي نهج التحول الثقافي الذي سأقدمه لك والذي سيسمح لك بتحويل العملية ونموذج التشغيل الحالي الذي تستخدمه للقيام بـ AppSec بشكل أساسي، إلى نهج DevSecOps الحديث.

متعلق ب:كيف يمكن للمطورين من جميع مستويات المهارة الاستفادة بشكل أفضل من الذكاء الاصطناعي

يستخدم العديد من مفاهيم DevOps، وهو أمر مألوف لديهم بالفعل. لتحفيزك على الالتزام بالمفهوم، هذه هي في الأساس عملية مخطط التحول التي طورتها في Comcast حيث قمت بالتقاط البيانات الخاصة بها.

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

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

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

شاهد الندوة التعليمية عبر الإنترنت المؤرشفة “كيفية تضخيم DevOps باستخدام DevSecOps” عند الطلب اليوم.





Source link

زر الذهاب إلى الأعلى