DevSecOps الخوف والبغض

كان لدينا 2 من محللي الكود ، و 4 أدوات اختبار ديناميكية ، وحرفنا الخاصة ، و 250 برنامج نصي. لا يعني ذلك أن كل هذا مطلوب في العملية الحالية ، ولكن بمجرد أن تبدأ في تنفيذ DevSecOps ، عليك أن تذهب إلى النهاية.

مصدر. الشخصيات التي أنشأها جاستن رويلاند ودان هارمون.

ما هو SecDevOps؟ ماذا عن DevSecOps؟ ما هي الاختلافات؟ أمان التطبيق - ما هو؟ لماذا لم يعد النهج الكلاسيكي يعمل بعد الآن؟ كل هذه الأسئلة تعرف الإجابة يوري شبالين من أمن سمك أبو سيف. سيجيب Yuriy على كل شيء بالتفصيل ويحلل مشاكل الانتقال من نموذج أمان التطبيقات الكلاسيكي إلى عملية DevSecOps: كيفية التعامل بشكل صحيح مع تكامل عملية التطوير الآمن في عملية DevOps وعدم كسر أي شيء ، وكيفية المرور بالمراحل الرئيسية اختبار الأمان ، وما هي الأدوات التي يمكن استخدامها ، وكيفية اختلافها وكيفية تكوينها بشكل صحيح لتجنب المزالق.

حول المتحدث: يوري شبالين - كبير مهندسي الأمن في الشركة أمن سمك أبو سيف. مسؤول عن تنفيذ SSDL ، عن التكامل الشامل لأدوات تحليل التطبيق في نظام واحد للتطوير والاختبار. 7 سنوات خبرة في مجال أمن المعلومات. عمل في Alfa-Bank و Sberbank و Positive Technologies ، التي تطور البرمجيات وتقدم الخدمات. المتحدثين في المؤتمرات الدولية ZerONights، PHDays، RISSPA، OWASP.

أمان التطبيق: ما هو؟

أمن التطبيق هو قسم الأمان المسؤول عن أمان التطبيق. لا يتعلق الأمر بالبنية التحتية أو أمان الشبكة ، بل يتعلق بما نكتبه وما يعمل عليه المطورون - هذه هي العيوب ونقاط الضعف في التطبيق نفسه.

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

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

تم تفصيل SDLC الكنسي بشكل كبير في منهجيات مختلفة - OpenSAMM و BSIMM و OWASP. المنهجيات تختلف ، لكنها متشابهة بشكل عام.

أمن البناء في نموذج النضج

احبها اكثر بسيم - أمن البناء في نموذج النضج. أساس المنهجية هو تقسيم عملية أمان التطبيقات إلى 4 مجالات: الحوكمة والاستخبارات ونقاط اتصال SSDL والنشر. يحتوي كل مجال على 12 ممارسة ، والتي يتم تمثيلها في 112 نشاطًا.

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

لماذا DevSecOps

DevOps هي عملية كبيرة بشكل عام يجب الاهتمام بالأمان فيها.

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

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

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

الانتقال إلى DevSecOps

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

لا يكفي مجرد تضمين الأدوات في عملية DevOps - فالتواصل والتفاهم بين المشاركين في العملية أمر مهم.

الناس أهم من الأدوات

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

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

أولاً ، صف النتيجة التي تريدها وكيف ستبدو العملية. سيساعد هذا على فهم أدوار الأداة والأمان في العملية.

ابدأ بما هو مستخدم بالفعل

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

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

- الآن ، في مكان ما في الملاحظات كان هناك مسار حيث يقع هذا المستند.

نتيجة لذلك ، تلقينا المستند بعد أسبوع.

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

من الأسهل إعادة تنسيق ما هو موجود بالفعل واستخدامه للبدء.

استخدم أبطال الأمان

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

Security Champions هو شخص ضمن فريق التطوير مهتم بأمان منتجك.

يعد Security Champion نقطة دخول لفريق التطوير ومبشر أمني مدمج في واحد.

عادة ، عندما يأتي ضابط الأمن إلى فريق التطوير ويشير إلى خطأ في الكود ، فإنه يتلقى إجابة مفاجئة:

- ومن أنت؟ اراك لاول مره كل شيء على ما يرام بالنسبة لي - وضع صديقي الكبير "تطبيق" على مراجعة التعليمات البرمجية ، ننتقل إلى الأمام!

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

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

لذلك ضع في اعتبارك تطبيق Security Champions وتوسيع نفوذ فريق الأمان. بالنسبة للبطل نفسه ، يعد هذا مفيدًا أيضًا: التطوير المهني في مجال جديد ، وتوسيع الآفاق التقنية ، وضخ المهارات الفنية والإدارية والقيادية ، وزيادة القيمة السوقية. هذا عنصر من عناصر الهندسة الاجتماعية ، "عيناك" في فريق التطوير.

مراحل الاختبار

نموذج 20 في 80 يقول أن 20٪ من الجهود تعطي 80٪ من النتائج. هذه الـ 20٪ هي ممارسات تحليل التطبيقات التي يمكن ويجب أن تتم آليًا. ومن أمثلة هذه الأنشطة التحليل الساكن - كبار المستشارينتحليل ديناميكي - داست ، и التحكم في المصدر المفتوح. سأخبرك بالمزيد عن الأنشطة ، بالإضافة إلى الأدوات ، والميزات التي نواجهها عادة عند تقديمها في العملية ، وكيفية القيام بذلك بشكل صحيح.

مشاكل الأداة الرئيسية

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

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

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

لا تكامل مع الأدوات الموجودة. انظر إلى الأدوات من حيث التكامل مع ما تستخدمه بالفعل. على سبيل المثال ، إذا كان لديك Jenkins أو TeamCity ، فتحقق من تكامل الأدوات مع هذا البرنامج ، وليس مع GitLab CI ، التي لا تستخدمها.

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

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

ميزات العملية

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

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

- لديك نقاط ضعف هنا ، فلن تذهب إلى أي مكان آخر!

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

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

- يا رفاق ، لديك مشاكل ، يرجى الانتباه إليها.

في مرحلة UAT ، نعرض مرة أخرى تحذيرات حول نقاط الضعف ، وفي مرحلة الخروج في الحفلة الراقصة نقول:

"يا رفاق ، لقد حذرناكم عدة مرات ، لم تفعلوا أي شيء - لن نسمح لكم بذلك.

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

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

ليست كل مشكلات جودة البرامج هي مشكلات أمنية. لكن جميع مشاكل الأمان تتعلق بجودة البرنامج. شريف منصور ، اكسبيديا.

نظرًا لأن جميع نقاط الضعف هي نفس العيوب ، فيجب أن تكون موجودة في نفس المكان الذي توجد فيه جميع عيوب التطوير. لذا انسَ التقارير وملفات PDF المخيفة التي لا يقرأها أحد.

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

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

التحليل الساكن - SAST

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

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

سلبيات هو عدم وجود دعم للغات المطلوبة.

التكاملات المطلوبة ، التي يجب أن تكون في الأدوات ، في رأيي الشخصي:

• أداة التكامل: Jenkins و TeamCity و Gitlab CI.
• بيئة التطوير: Intellij IDEA، Visual Studio. من الملائم أكثر للمطور ألا يصعد إلى واجهة غير مفهومة لا تزال بحاجة إلى تذكر ، ولكن أن يرى جميع عمليات الدمج ونقاط الضعف الضرورية التي وجدها في مكان العمل في بيئة التطوير الخاصة به.
• مراجعة الكود: SonarQube والمراجعة اليدوية.
• أجهزة تعقب العيوب: Jira و Bugzilla.

تُظهر الصورة بعضًا من أفضل ممثلي التحليل الساكن.

ليست الأدوات هي المهمة ، ولكن العملية ، لذلك هناك حلول مفتوحة المصدر جيدة أيضًا لتشغيل العملية.

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

كيف يمكن دمج هذا إذا كنت في بداية الرحلة وليس لديك أي شيء: لا CI ولا Jenkins ولا TeamCity؟ ضع في اعتبارك تكامل العملية.

التكامل على مستوى CVS

إذا كان لديك Bitbucket أو GitLab ، فيمكنك القيام بالتكامل على المستوى نظام الإصدارات المتزامنة.

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

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

التكامل مع نظام مراجعة الكود

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

التكامل مع SonarQube

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

التكامل على مستوى CI

هنا أيضًا ، كل شيء بسيط للغاية:

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

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

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

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

مثال على بوابة الأمن هو نظير لبوابة الجودة ، من حيث وجود وعدد نقاط الضعف في الكود.

نحن نتكامل مع SonarQube - تم تثبيت المكون الإضافي ، كل شيء مريح للغاية ورائع.

تكامل البيئة التنموية

خيارات التكامل:

• بدء مسح من بيئة التطوير حتى قبل الالتزام.
• عرض النتائج.
• تحليل النتائج.
• التزامن مع الخادم.

هذه هي الطريقة التي يبدو بها الحصول على النتائج من الخادم.

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

مفتوحة المصدر

هذا هو موضوعي المفضل. يستخدم الجميع مكتبات مفتوحة المصدر - لماذا تكتب مجموعة من العكازات والدراجات بينما يمكنك أن تأخذ مكتبة جاهزة يتم فيها تنفيذ كل شيء بالفعل؟

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

تحليل مفتوح المصدر - OSA

تتضمن الأداة ثلاث خطوات رئيسية.

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

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

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

الميزات:

• سياسات مختلفة لمراحل التنمية المختلفة.
• مراقبة المكونات في بيئة صناعية.
• السيطرة على المكتبات في محيط المنظمة.
• دعم لأنظمة البناء واللغات المختلفة.
• تحليل صور Docker.

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

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

عملية التكامل

مراقبة مكتبة المحيطالتي يتم تنزيلها من مصادر خارجية. لدينا مستودعات خارجية وداخلية. على سبيل المثال ، لدينا Nexus داخل Event Central ، ونريد التأكد من عدم وجود ثغرات أمنية ذات حالة "حرجة" أو "عالية" داخل مستودعنا. يمكنك إعداد وكلاء باستخدام أداة Nexus Firewall Lifecycle بحيث يتم قطع هذه الثغرات الأمنية وعدم تضمينها في المستودع الداخلي.

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

تكامل الأداة: نيكزس وجفروج.

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

تكامل القرص المضغوط. هذه ميزة رائعة أحبها حقًا وقد تحدثت عنها بالفعل - مراقبة ظهور نقاط ضعف جديدة في بيئة صناعية. يعمل مثل هذا.

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

• عند البناء ، نتحقق من عدم انزلاق أي شخص لأي شيء سيء ، وأن جميع المكونات آمنة ولم يجلب أحد أي شيء خطير على محرك الأقراص المحمول.
• لدينا فقط مكونات موثوقة في المستودع.
• عند النشر ، نتحقق مرة أخرى من الحزمة نفسها: war أو jar أو DL أو Docker image للتأكد من أنها تتوافق مع السياسة.
• عند دخول البيئة الصناعية ، نراقب ما يحدث في البيئة الصناعية: تظهر نقاط الضعف الحرجة أو لا تظهر.

التحليل الديناميكي - DAST

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

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

- نعم ، هناك مشكلة إلغاء التسلسل هنا ، ولكن ليس هنا.

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

• حمولة عالية على شبكة خادم التطبيق.
• لا تكاملات.
• القدرة على تغيير إعدادات التطبيق الذي تم تحليله.
• لا يوجد دعم للتقنيات الضرورية.
• صعوبة الإعداد.

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

"يا رفاق ، هل تمزح معي ؟! قدمنا ​​لك حسابات ، ووضعت الموقف!

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

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

بعض الموارد التي نستخدمها عادة.

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

عملية التكامل

التكامل جيد جدًا وبسيط: بدء الفحص بعد التثبيت الناجح تطبيقات على المنصة و المسح بعد اختبار التكامل الناجح.

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

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

عملية

قليلا معمم حول العملية بشكل عام وحول عمل كل أداة على وجه الخصوص. جميع التطبيقات مختلفة - أحدهما يعمل بشكل أفضل مع التحليل الديناميكي ، والآخر مع التحليل الثابت ، والثالث مع تحليل OpenSource ، أو pentests ، أو أي شيء آخر بشكل عام ، على سبيل المثال ، الأحداث مع WAF.

يجب التحكم في كل عملية.

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

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

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

لدى المديرين والمطورين ومهندسي الأمان نقطة دخول واحدة يمكنهم من خلالها معرفة ما يتم تشغيله وتكوين عمليات الفحص وتشغيلها والحصول على نتائج الفحص وإرسال المتطلبات. نحاول الابتعاد عن قطع الورق ، وترجمة كل شيء إلى شيء بشري يستخدمه التطوير - صفحات عن التقاء مع الحالة والمقاييس ، أو عيوب في Jira أو في متتبعات عيوب مختلفة ، أو التضمين في عملية متزامنة / غير متزامنة في CI / CD.

الوجبات السريعة الرئيسية

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

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

ابدأ بما هو موجود بالفعل: المتطلبات ، الهندسة المعمارية ، الشيكات الجزئية ، التدريبات ، المبادئ التوجيهية. ليس من الضروري تطبيق جميع الممارسات على الفور على جميع المشاريع - تحرك بشكل متكرر. لا يوجد معيار واحد تجربة وجرب أساليب وحلول مختلفة.

علامة متساوية بين عيوب IS والعيوب الوظيفية.

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

إذا كان حجم فريق البكالوريا الدولية صغيرًا - استخدام أبطال الأمن.

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

متطلبات الأداة.

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

تم اختيار تقرير Yuriy كأحد أفضل التقارير في DevOpsConf 2018. للتعرف على المزيد من الأفكار المثيرة للاهتمام والحالات العملية ، تعال إلى Skolkovo في 27 و 28 مايو DevOpsConf داخل مهرجان RIT ++. والأفضل من ذلك ، إذا كنت على استعداد لمشاركة تجربتك ، إذن يتقدم أرسل تقريرك بحلول 21 أبريل.

المصدر: www.habr.com