1 في 100: كيفية تصميم الفرق لسد الفجوة الأمنية

1 في 100

حتى إذا كنت تعمل في مؤسسة كبيرة ، فمن المحتمل أنه يمكنك حفظ أسماء جميع الأشخاص الذين يعملون في مجال تكنولوجيا المعلومات. ذلك لأن نسبة المطورين إلى الأمان هي 100: 1 ، وفقًا لمسح حديث (تشير نفس الدراسة إلى نسبة 10: 1 من dev إلى ops). أبلغت الدراسات السابقة عن نسب من 100: 3 إلى 100: 6 ، لذلك هناك بعض التقدم ولكن ليس بالسرعة الكافية.

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

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

فما هي الخيارات المتاحة لدينا لسد هذه الفجوة الأمنية؟

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

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

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

تتبادر طوبولوجيتان متميزتان (وربما مكملتان) لفريق إلى الذهن:

أ) المسؤوليات الأمنية المشتركة بالكامل

ب) الأمن كفريق تمكين

ما هي الاختلافات ، إيجابيات وسلبيات كل نهج؟

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

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

الهدف ليس تخصيص الشخص الأمني ​​لجميع أعمال الأمان ، وإلا فإننا نقوم بنقل صومعة على مستوى ماكرو (فريق أمان معزول) إلى المستوى الجزئي (عضو فريق معزول).
كل فريق منتج - تم تصويره على أنه دائرة صفراء - يضم 7 إلى 9 أعضاء من الفريق ، حيث يكون واحد على الأقل من أفراد الأمن على شكل حرف T - يتم تصويرهم داخل دائرة خضراء - ولكن يشارك الآخرون أيضًا في أعمال الأمان

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

الايجابيات

  • سوف ترتفع ملكية فريق الأمن ، مما يؤدي إلى حل حادث أمني أسرع (غير تافه) ، وربما الأهم من ذلك ، التعلم منه لتجنب تكرار الألم في المستقبل.
  • نظرًا لأن هناك قيودًا على الحجم الطبيعي للفرق (من 8 إلى 9 أشخاص) ، يجب أن تقترب نسبة موظفي تكنولوجيا المعلومات إلى موظفي الأمن (على شكل حرف T) من 10 إلى 1 بمرور الوقت باستخدام طوبولوجيا الفريق هذه. إن التنوع في الخلفية التقنية وحدها سيجلب فوائد من حيث النهج للمشاكل والأولويات.
  • سوف يؤدي الانتقال إلى هذا الهيكل إلى إرسال إشارة لا يمكن إنكارها إلى الجميع في المؤسسة مفادها أن الأمان أصبح الآن مواطنًا من الدرجة الأولى في منتجاتنا.

سلبيات

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

الاستدلال

  • هل لدى مؤسستك بالفعل فرق متعددة الوظائف في مكانها الصحيح ، حيث تدمج أصحاب الأعمال وتملك مسؤولية ضمان الجودة ومراقبة وتشغيل التطبيقات التي يطورونها؟
  • هل تعرض المنتجات (أو الخدمات) ملفات تعريف مخاطر مختلفة جدًا؟
  • هل تعمل المنتجات (أو الخدمات) على مجموعات التكنولوجيا والبنية التحتية غير المتجانسة؟

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

الأمان كفريق التمكين يعني أن فريق الأمان المخصص يوفر الدعم والإرشاد (على سبيل المثال ، إنتاج إرشادات تطوير آمنة) لفرق تطوير المنتج.

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

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

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

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

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

دور فريق أمني مركزي يوفر التوجيه بدلاً من القيام بعمل حماية المنتج (الائتمان: Pablo Jensen ، CTO في Sportradar - الشرائح من عرضه QCon London 2018)

الايجابيات

  • إطار زمني أقصر للانتقال إلى نموذج التمكين من فريق أمان معزول تقليدي يقوم بمعظم العمل الأمني.
  • لن يتطلب عددًا كبيرًا من التعيينات الجديدة ، وبالتالي تجنب كل الجهود المرتبطة بذلك وتعطيل الفريق. يجب أن يكون التركيز هنا على التأكد من أن فريق التمكين ككل لديه كل المهارات اللينة المطلوبة ، بالإضافة إلى المهارات الفنية.

سلبيات

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

الاستدلال

  • هل هناك عدد صغير من فرق تطوير المنتج (مما يسمح بتعاون أوثق مع فريق الأمان)؟
  • هل يُظهر أعضاء فريق المنتج الاهتمام بمواضيع الأمان وشهية التعلم (على سبيل المثال حضور المؤتمرات الفنية أو الاجتماعات)؟
  • هل يشمل حل الحوادث المتعلقة بالأمن في الإنتاج بطبيعة الحال كلاً من أفراد الأمن والتنمية (على عكس لعبة اللوم حيث يتجنب كل جانب من المسؤولية)؟

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

خاتمة

رفع DevSecOps من مستوى الأمان في تقنية المعلومات ، وكشف التدفق المنتظم للخروقات الخطيرة عن الفجوة الأمنية في معظم المؤسسات. في هذا المنشور ، قدّمتُ مقاربتين محتملتين لسد هذه الفجوة (المسؤولية الأمنية المشتركة بالكامل مقابل الأمن كفريق تمكين) ، بالإضافة إلى إيجابياتهما وسلبياتهما ، والاستدلال بناءً على السياق.

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

ما طوبولوجيات الفريق الأخرى واستراتيجيات الأمان التي رأيتها في مؤسساتك أو عملائك؟ يرجى التعليق أدناه أو البريد الإلكتروني لي في:

لي في manuelpais دوت نت