كجزء من أنشطتهم المهنية ، يتعين على المطورين والمختصين والعاملين في مجال الأمن التعامل مع عمليات مثل إدارة الثغرات الأمنية (VM) و (Secure) SDLC.
تحت هذه العبارات ، توجد مجموعات مختلفة من الممارسات والأدوات المستخدمة المتشابكة ، على الرغم من اختلاف مستهلكيها.
لم يصل التقدم التقني بعد إلى نقطة استبدال شخص بأداة واحدة لتحليل أمان البنية التحتية والبرامج.
من المثير للاهتمام أن نفهم سبب ذلك ، وما هي المشاكل التي تواجهها.
العمليات
تهدف عملية إدارة الثغرات الأمنية إلى المراقبة المستمرة لأمن البنية التحتية وإدارة التصحيح.
تم تصميم عملية Secure SDLC ("دورة التطوير الآمن") لدعم أمان التطبيق أثناء التطوير والتشغيل.
جزء مماثل من هذه العمليات هو عملية تقييم الثغرات الأمنية - تقييم الثغرات الأمنية ومسح الثغرات الأمنية.
الفرق الرئيسي في المسح داخل VM و SDLC هو أنه في الحالة الأولى ، يتمثل الهدف في اكتشاف الثغرات المعروفة في برامج الجهات الأخرى أو في التكوين. على سبيل المثال ، إصدار قديم من Windows أو سلسلة المجتمع الافتراضية لـ SNMP.
في الحالة الثانية ، الهدف هو اكتشاف نقاط الضعف ليس فقط في مكونات الطرف الثالث (التبعيات) ، ولكن في المقام الأول في رمز المنتج الجديد.
هذا يؤدي إلى اختلافات في الأدوات والأساليب. في رأيي ، مهمة العثور على ثغرات أمنية جديدة في التطبيق هي أكثر إثارة للاهتمام ، لأنه لا يتعلق بإصدارات البصمات ، وجمع الشعارات ، وفرز كلمات المرور ، إلخ.
يتطلب المسح الآلي عالي الجودة لنقاط الضعف في التطبيق خوارزميات تأخذ في الاعتبار دلالات التطبيق والغرض منه والتهديدات المحددة.
غالبًا ما يمكن استبدال ماسح البنية التحتية
بجهاز ضبط الوقت ، كما قال
avleonov . النقطة المهمة هي أنه ، من الناحية الإحصائية البحتة ، يمكنك اعتبار البنية الأساسية لديك عرضة للخطر إذا لم تقم بتحديثها ، على سبيل المثال ، لمدة شهر.
الأدوات
يمكن إجراء المسح ، وكذلك تحليل الأمان ، كمربع أسود أو مربع أبيض.
الصندوق الاسود
عند مسح الصندوق الأسود ، يجب أن تكون الأداة قادرة على العمل مع الخدمة من خلال نفس الواجهات التي يعمل معها المستخدمون من خلالها.
تبحث ماسحات البنية التحتية (Tenable Nessus و Qualys و MaxPatrol و Rapid7 Nexpose وما إلى ذلك) عن منافذ الشبكة المفتوحة وجمع "الشعارات" وتحديد إصدارات البرامج المثبتة والبحث عن معلومات حول الثغرات الأمنية في هذه الإصدارات في قاعدة معارفهم. يحاولون أيضًا اكتشاف أخطاء التكوين ، مثل كلمات المرور الافتراضية أو الوصول المفتوح إلى البيانات ، وأصفار SSL الضعيفة ، إلخ.
تعرف ماسحات تطبيق الويب (Acunetix WVS ، و Netsparker ، و Burp Suite ، و OWASP ZAP ، وما إلى ذلك) أيضًا كيفية تحديد المكونات المعروفة وإصداراتها (على سبيل المثال ، CMS ، والأطر ، ومكتبات JS). الخطوات الرئيسية للماسح الضوئي هي الزحف والاندثار.
أثناء الزحف ، يجمع الماسح الضوئي معلومات حول واجهات التطبيق الحالية ، ومعلمات HTTP. أثناء الدمج ، يتم استبدال جميع المعلمات المكتشفة ببيانات متحولة أو تم إنشاؤها من أجل إثارة خطأ واكتشاف الثغرة الأمنية.
تنتمي هذه الماسحات الضوئية للتطبيق إلى فئتي DAST و IAST - اختبار أمان التطبيق الديناميكي والتفاعلي ، على التوالي.
مربع أبيض
المسح الأبيض لديها المزيد من الاختلافات.
طوال العملية ، غالبًا ما تُمنح ماسحات VM (Vulners و Incsecurity Couch و Vuls و Tenable Nessus وما إلى ذلك) الوصول إلى الأنظمة عن طريق إجراء فحص مصدق عليه. وبالتالي ، يمكن للماسح الضوئي تنزيل الإصدارات المثبتة من الحزم ومعلمات التكوين مباشرة من النظام ، دون تخمينها على شعارات خدمات الشبكة.
الفحص أكثر دقة وكاملة.
إذا تحدثنا عن المسح الأبيض (CheckMarx ، HP Fortify ، Coverity ، RIPS ، FindSecBugs ، وما إلى ذلك) للتطبيقات ، فإننا نتحدث عادة عن تحليل الكود الثابت واستخدام الأدوات المقابلة لفئة SAST - اختبار أمان التطبيق الثابت.
المشاكل
هناك العديد من المشاكل مع المسح! يجب أن أتعامل مع معظمهم شخصيًا في إطار تقديم خدمة لبناء عمليات المسح والتنمية الآمنة ، وكذلك عند إجراء تحليل الأمان.
سوف أحدد ثلاث مجموعات رئيسية من المشاكل ، والتي أكدتها المحادثات مع المهندسين ومديري خدمات أمن المعلومات في مختلف الشركات.
قضايا فحص تطبيق الويب
- تعقيد التنفيذ. يجب نشر الماسحات الضوئية وتهيئتها وتخصيصها لكل تطبيق ، وتخصيص بيئة اختبار للمسح وتنفيذها في عملية CI / CD لتكون فعالة. خلاف ذلك ، سيكون إجراءً رسميًا غير مجدي ، مع إعطاء إيجابيات كاذبة فقط
- مدة المسح. لا تعمل الماسحات الضوئية ، حتى في عام 2019 ، بشكل سيئ مع إلغاء البيانات المكررة للواجهة ويمكنها مسح آلاف الصفحات لمدة 10 أيام مع 10 معلمات لكل منها ، معتبرة أنها مختلفة ، على الرغم من أن نفس الكود مسؤول عنها. في الوقت نفسه ، يجب اتخاذ قرار النشر إلى الإنتاج داخل دورة التطوير بسرعة
- توصيات هزيلة. تقدم الماسحات الضوئية توصيات عامة إلى حد ما ، وليس من الممكن دائمًا للمطور أن يفهم بسرعة كيفية تقليل مستوى المخاطرة ، والأهم من ذلك ، ما إذا كان يجب القيام به في الوقت الحالي أم لا بالخوف
- تأثير مدمر على التطبيق. قد تنفذ الماسحات الضوئية هجومًا على DoS على التطبيق ، ويمكنها أيضًا إنشاء عدد كبير من الكيانات أو تعديل الكيانات الموجودة (على سبيل المثال ، إنشاء عشرات الآلاف من التعليقات على المدونة) ، لذلك لا تقم بإطلاق مسح ضوئي في برنامج prod
- كشف ضعف جودة منخفضة. عادةً ما تستخدم الماسحات الضوئية صفيف حمولات ثابتة ويمكنها أن تتجاهل بسهولة ثغرة أمنية لا تنسجم مع سيناريو سلوك التطبيق المعروف.
- لا يفهم الماسح الضوئي وظائف التطبيق. لا تعرف الماسحات الضوئية ما هي "الخدمات المصرفية عبر الإنترنت" و "الدفع" و "التعليق". بالنسبة لهم ، لا يوجد سوى روابط ومعلمات ، بحيث تظل هناك طبقة كاملة من الثغرات المحتملة في منطق العمل غير مكشوفة تمامًا ، ولن يخمنوا الكتابة المزدوجة أو إلقاء نظرة خاطفة على بيانات الآخرين عن طريق الهوية أو إنهاء الرصيد من خلال التقريب
- سوء فهم الماسح الضوئي من دلالات الصفحة. لا تعرف الماسحات الضوئية كيفية قراءة الأسئلة الشائعة ، ولا يعرفون كيفية التعرف على كلمة التحقق ، فلن يخمنوا بأنفسهم كيفية التسجيل ، ثم يحتاجون إلى تسجيل الدخول ، بحيث لا يمكنك النقر فوق "تسجيل الخروج" ، وكيفية تسجيل الطلبات عند تغيير قيم المعلمات. نتيجة لذلك ، قد لا يتم مسح معظم التطبيق على الإطلاق.
مصدر قانون المسح الضوئي القضايا
- ايجابيات كاذبة. يعد التحليل الثابت مهمة صعبة ، في حلها ، من الضروري اللجوء إلى الكثير من الحلول الوسط. غالبًا ما تضطر إلى التضحية بالدقة ، وحتى الماسحات الضوئية للشركات غالية الثمن تنتج كمية هائلة من الإيجابيات الخاطئة
- تعقيد التنفيذ. لزيادة دقة واكتمال التحليل الثابت ، من الضروري تحسين قواعد المسح ، وكتابة هذه القواعد قد تستغرق وقتًا طويلاً للغاية. في بعض الأحيان يكون من السهل العثور على جميع الأماكن في الكود مع وجود نوع من الأخطاء وإصلاحها ، بدلاً من كتابة قاعدة للكشف عن مثل هذه الحالات
- عدم وجود دعم التبعية. تعتمد المشروعات الكبيرة على عدد كبير من المكتبات والأطر التي تعمل على توسيع قدرات لغة البرمجة. إذا لم يكن لدى قاعدة معارف الماسح الضوئي معلومات حول "المصارف" في هذه الأطر ، فستصبح هذه نقطة عمياء ولن يفهم الماسح الضوئي حتى الشفرة
- مدة المسح. العثور على نقاط الضعف في التعليمات البرمجية مهمة صعبة من حيث الخوارزميات. لذلك ، قد تتأخر العملية وتتطلب موارد حاسوبية كبيرة.
- تغطية منخفضة. على الرغم من استهلاك الموارد ومدة الفحص ، لا يزال يتعين على مطوري أدوات SAST اللجوء إلى الحلول الوسط وتحليل جميع الظروف التي قد يكون البرنامج فيها
- استنساخ الاكتشافات. من الجيد الإشارة إلى سطر معين واستدعاء المكالمة التي تؤدي إلى مشكلة عدم الحصانة ، ولكن في الواقع لا يوفر الماسح الضوئي في كثير من الأحيان معلومات كافية للتحقق من وجود ثغرة أمنية خارجية. بعد كل شيء ، قد يكون الخلل أيضًا في حالة وفاة ، وهو أمر يتعذر الوصول إليه بالنسبة للمهاجمين
مشاكل فحص البنية التحتية
- المخزون غير كاف. في البنى التحتية الكبيرة ، ولا سيما مفصولة جغرافيا ، غالبا ما يكون من الصعب فهم المضيفين الذين يحتاجون إلى المسح. بمعنى آخر ، ترتبط مهمة الفحص ارتباطًا وثيقًا بمهمة إدارة الأصول.
- ضعف الأولويات. غالبًا ما تنتج الماسحات الضوئية للشبكة العديد من النتائج ذات العيوب التي لا يمكن استغلالها من الناحية العملية ، ولكن مستوى المخاطرة فيها مرتفع رسميًا. يتلقى المستهلك تقريرًا يصعب تفسيره ، وليس من الواضح ما يجب إصلاحه أولاً
- توصيات هزيلة. غالبًا ما تحتوي قاعدة معارف الماسحة الضوئية على معلومات عامة جدًا حول مشكلة عدم الحصانة وكيفية إصلاحها ، لذلك سيتعين على المسؤولين التسلل إلى Google. الموقف أفضل قليلاً مع الماسحات الضوئية البيضاء التي يمكنها إصدار أمر محدد لإصلاحه
- العمل اليدوي. يمكن أن تحتوي البنية التحتية على العديد من العقد ، مما يعني احتمال وجود العديد من أوجه القصور ، والتي يجب تفكيكها وتحليلها يدويًا في كل تكرار
- تغطية سيئة. تعتمد جودة مسح البنية التحتية بشكل مباشر على حجم قاعدة المعرفة حول الثغرات وإصدارات البرامج. في الوقت نفسه ، اتضح أنه حتى قادة السوق ليس لديهم قاعدة معرفة شاملة ، وهناك الكثير من المعلومات في قواعد بيانات الحلول المجانية التي لا يملكها القادة
- مشاكل مع الترقيع. تصحيح الأخطاء الأكثر شيوعًا في البنية التحتية هو تحديث الحزمة أو تغيير ملف التكوين. المشكلة الكبيرة هنا هي أن النظام ، وخاصة الإرث القديم ، يمكن أن يتصرف بشكل غير متوقع نتيجة للترقية. في جوهرها ، سوف تضطر إلى إجراء اختبارات التكامل على البنية التحتية الحية في الإنتاج
النهج
كيف تكون؟
سوف أخبركم أكثر عن الأمثلة وكيفية التعامل مع العديد من هذه المشاكل في الأجزاء التالية ، لكن الآن سأشير إلى المجالات الرئيسية التي يمكنك العمل فيها:
- تجميع أدوات المسح المختلفة. مع الاستخدام الصحيح للماسحات الضوئية المتعددة ، يمكن تحقيق زيادة كبيرة في قاعدة المعرفة وجودة الكشف. يمكنك العثور على نقاط ضعف أكثر من إجمالي جميع الماسحات الضوئية التي تم إطلاقها بشكل منفصل ، في حين أنه من الممكن إجراء تقييم أكثر دقة لمستوى المخاطرة وتقديم توصيات أكثر
- تكامل SAST و DAST. يمكنك زيادة تغطية DAST ودقة SAST من خلال مشاركة المعلومات بينهما. من المصدر يمكنك الحصول على معلومات حول الطرق الحالية ، وباستخدام DAST ، يمكنك التحقق مما إذا كانت الثغرة الأمنية مرئية من الخارج
- آلة التعلم ™ . في عام 2015 ، تحدثت عن (وحتى الآن ) حول استخدام الإحصاءات لإعطاء المتسللين الحدس من الماسحات الضوئية وتسريعها. هذا هو بالتأكيد الغذاء لتطوير تحليل الأمن الآلي في المستقبل.
- دمج IAST مع autotests و OpenAPI. في إطار خط أنابيب CI / CD ، من الممكن إنشاء عملية مسح تعتمد على أدوات تعمل كوكيل HTTP واختبارات وظيفية تعمل على HTTP. ستوفر اختبارات وعقود OpenAPI / Swagger الماسح الضوئي المعلومات المفقودة حول تدفقات البيانات ، وستمكن من فحص التطبيق في حالات مختلفة
- التكوين الصحيح. لكل تطبيق وبنية تحتية ، تحتاج إلى إنشاء ملف تعريف مسح مناسب يأخذ في الاعتبار عدد وطبيعة الواجهات والتقنيات المستخدمة
- تخصيص الماسحات الضوئية. في كثير من الأحيان ، لا يمكن فحص تطبيق ما دون الانتهاء من الماسح الضوئي. مثال على ذلك عبارة عن بوابة دفع يجب توقيع كل طلب فيها. بدون كتابة موصل لبروتوكول البوابة ، ستفوق الماسحات الضوئية الطلبات التي تحمل توقيع خاطئ بلا كلل. من الضروري أيضًا كتابة ماسحات ضوئية متخصصة لنوع معين من العيوب ، مثل Insecure Direct Object Reference
- إدارة المخاطر. يتيح لك استخدام الماسحات الضوئية المتنوعة والتكامل مع الأنظمة الخارجية ، مثل إدارة الأصول وإدارة التهديدات ، استخدام العديد من المعلمات لتقييم مستوى المخاطرة ، بحيث يمكن للإدارة الحصول على صورة مناسبة للحالة الأمنية الحالية للتطوير أو البنية التحتية
ترقبوا ودعونا نعطل مسح الثغرات الأمنية!