تعمل ألكسندرا سفاتيكوفا كخبيرة في أمن المعلومات في Odnoklassniki. منذ أكثر من 8 سنوات ، انتقلت من تطوير Java إلى اختبار أمان التطبيق.
قابلناها حيث ناقشنا:
- هل من الصعب على المطور التبديل إلى تحليلات التطبيق؟
- الاختلافات في أداء المكب ، والباحث والمحلل ؛
- دورة حياة تطوير الأمن أو SDLC ؛
- دور الرجل في البحث عن نقاط الضعف ؛
- كيف هي الأمور مع تحليلات الأمن في شركات أخرى.
لن يكون هناك المتشددين في هذا المقال - يمكنك متابعته إلى Heisenbug 2019 في موسكو ، حيث ستتحدث ألكسندرا عن اختبار الأمان الثابت. سننتقل إلى تقريرها في نهاية المنشور ، ولكن الآن ، مرحبًا بك في cat.
تسجيل الدخول إلى أمان التطبيق ليس صعباً كما يبدو
"لمن درست؟" لماذا انخرطت في أمان التطبيق؟
- ربما لست مثالاً يحتذى به (يضحك) . لقد درست كمبرمج ، وشيء مثل "هندسة البرمجيات" مكتوب في الدبلوم. عملت أولاً كمطور للجوال ، ثم تحولت إلى تطوير الويب في Java. بعد العثور على وظيفة أخرى كمبرمج جافا ، انضممت إلى الفريق الذي يتعامل مع أمان التطبيق - الحفاظ على الجزء المتعلق بالأمان من التطوير. كانت هناك عملية منظمة تنظيماً جيداً ، وكانوا بحاجة إلى أشخاص للقيام بمراجعات الكود والمحللات الثابتة. وفقا لذلك ، كانوا يبحثون عن مبرمج جافا وكانوا على استعداد لتعليمه الأمن. كان يبدو مثيرا للاهتمام بالنسبة لي ، لذلك مكثت.
- ما رأيك ، هل ستبقى في هذا المجال لفترة طويلة ، أو هل سيتابع شيء ما هذه المرحلة؟
- أعتقد أنني سأبقى إلى الأبد ، لأنني كنت محللًا لأمن التطبيقات منذ عام 2011. لدي بالفعل تجربة تطوير أقل ، كما اتضح. لا ينبغي أن يخاف المبرمج من المهام الروتينية وإصلاح الأخطاء ، ولكن اختصاصي الأمان لديه خصوصية مختلفة ، فهو يجذبني أكثر.
- ما هي المجالات الإضافية مقارنة بالتنمية التقليدية التي كان عليك إتقانها؟
- في فجر حياتي المهنية ، كنت اختبار. إنه يحدد أدمغتك جيدًا: ترى النظام في صورة مجموعة من التعليمات البرمجية ، ولكن ليس كائنًا حيًا ، يمكن أن يتأثر بطرق مختلفة. لذلك فإن الفاحصين والمطورين لديهم اختلاف في التفكير.
على سبيل المثال ، قبل 10-15 سنة ، كان يعتقد أن على المختبرين كسر النظام والعثور على أي شكل من الأشكال. يحتاج المحترفون في مجال الأمن في بعض الأحيان إلى الحصول على وجهة نظر مماثلة. لذلك ، تحتاج إلى فهم كيفية عمل النظام ككل.
يتم التركيز على بعض المطورين على التفاصيل: فهم يعرفون كيفية عمل جزء من النظام ، لكنهم لا يفهمون كيف يتفاعل كل شيء. على سبيل المثال ، يعرف كيف يتم تنفيذ JS في المستعرض ، ولكن المطور لا يعرف كيف يعمل هذا المستعرض بشكل أفضل ويتواصل مع الخادم ، لماذا يتم ترتيب هذا بالشكل التالي. يجب أن ينظر المختبر من وجهة نظر عين الطائر لتقييم الترابط بين المكونات والتغيرات الضعيفة أو نقاط الضعف.
- وهندسة شيء ، على سبيل المثال ، أكوام الشبكة ، كان عليك أن تتعلم من نقطة الصفر؟ على سبيل المثال ، كيف تعمل JS ، الأمامية ، الخلفية؟
- من حيث المبدأ ، كنت بالفعل مطورًا متكاملاً ، لذلك أفهم كيف تعمل الواجهة الخلفية والواجهة الأمامية. يجب أن يكون لديك نظرة مستقبلية معينة ، ولكن تعمق التفاصيل يعتمد بالفعل على ما تقوم به. يعرف المطورين والمختبرين أنفسهم ، وفقًا للمشروع ، نوعًا من أشياء النظام (على سبيل المثال ، بروتوكولات الشبكة) أو معرفة المزيد عن الواجهة الأمامية. ذلك يعتمد على الظروف.
- إلى أي مدى يبدو الأمر واقعياً بالنسبة لك أن مطور برامج مكدس كامل أو اختبار مكدس كامل ، يشارك في البرمجة والتشغيل الآلي والاختبار ، سوف يذهب إلى تحليل التطبيقات ، أي ماذا تفعل؟
- إنه سهل للاختبار. تأكد من حصولك على بعض مهارات البرمجة وفهم كيفية بناء النظام من الداخل. لكن اختبار جيد دون هذا لم يعد موجودا. إذا كانت هذه هي الحالة ، فهناك مسألة التخصص: إنه بحاجة إلى قراءة حول الأمان وبعض التقنيات (على سبيل المثال ، Android أو النسخ الاحتياطي) ، أي ما يحاول إيجاد نقاط الضعف فيه.
يرى المطورون مشاركتهم في العملية بشكل مختلف قليلاً. لذلك ، بالنسبة للمطور هذه ثورة ، نظرة مختلفة على المهنة. من المهم للمطور أن يعمل شيء ما ، ولكن سيكون من الصعب عليه كسره.
Pentester ، rescher ومحلل أمان التطبيق: ما هو الفرق
- كما أفهمها ، يرتبط تخصصك بالمهندسين. كيف يقارن الباحثون بين الباحثين عن الضعف في اليوم صفر ، أم هل يتم خلطهم جميعًا في زجاجة واحدة وهل من الصعب حقًا معرفة من هو؟
- لا يوجد تقسيم واضح في المشاركات. لكنني سأخبرك بالمصطلحات التي يستخدمها الحزب.
هناك الكشافة الذين يبحثون عن منتج أو تقنية أو بروتوكول أو خادم في محاولة لإيجاد مشكلة مثيرة للاهتمام. يشير الاهتمام إلى مشكلة لم يتم العثور عليها مسبقًا ، أو تم تحديدها في مكان غير متوقع ، أو أنها مزيج معقد من المشكلات المعروفة مسبقًا. أستطيع أن أقول أنه كقاعدة عامة ، يتم العثور على جميع أنواع نقاط الضعف 0day بواسطة الكشافة.
Pentest هي الخدمة. لديك نظام وتريد أن تجد نقاط الضعف. مهمة المضايقات هي اختراق النظام. لن يتمكنوا من العثور على جميع المشاكل المحتملة. على سبيل المثال ، يمكن التخفيف من مشكلة عدم الحصانة بواسطة آليات الأمان الأخرى على مستويات مختلفة. سيبحث Pentester عن ما يتم استغلاله بالفعل ، وبعد ذلك يصدر تقريرًا ويغادر ، لأنه لا يوجد لديه مهمة زيادة أمان النظام أو ضبط عمليات التطوير.
هناك أيضًا أمان التطبيق أو تحليلات أمان المنتج. إنهم ، على العكس من ذلك ، ينظرون إلى النظام من الداخل. مهمتهم هي جعل النظام آمن. هذا يعني أن لديهم معلومات حول النظام ، وليس "الصندوق الأسود" بالنسبة لهم. من ناحية أخرى ، يصنفون المشاكل بشكل مختلف. يعتبر المحللون نقاط الضعف التي لا يمكن استغلالها في الوقت الحالي. على سبيل المثال ، هناك فجوة مهمة في لوحة المشرف ، ومن الواضح أنه يمكن الوصول إليها فقط من الشبكة الداخلية ، وبالتالي فهي ليست مخيفة للغاية. لكن من الداخل يفهم أنه في ظل ظروف معينة ، يمكن أن يحدث شيء فظيع.
يركز المحللون أكثر على دعم العملية. إذا وجد المبتدئون 20 خللًا ثم غادروا ، وكان المطورين الذين يقومون بعملية إصلاح الخلل يفعلون الشيء نفسه ، فلن يساعد المبتدئون هنا. لذلك ، سيكون فهم عدد الثغرات الموجودة في النظام ذا صلة فقط في تلك اللحظة.
- ثم يقوم محلل أمان التطبيق بذلك في هذه العملية ، يومًا بعد يوم؟
- نعم ، وفي الوقت نفسه ، يتم توجيه النشاط في اتجاهين. من ناحية ، تحتاج إلى البحث عن الثغرات الموجودة ومكافحتها. من ناحية أخرى ، هناك مهمة لجعل النظام أكثر أمانًا.
هذا يمكن تناوله بطرق مختلفة. على سبيل المثال ، قم ببناء عملية التطوير بحيث تكون هناك أخطاء أقل أو يتم اكتشافها بسرعة. أو قم بتنفيذ آليات من شأنها أن تقلل من خطر حدوث ثغرة أمنية في الإنتاج. هناك عدة طرق لضمان أمان النظام.
- لذلك ، يرتبط عمل تحليلات أمان التطبيق بشكل وثيق مع الفرق وعملية التطوير في الداخل بالضبط؟
- نعم ، يجب على محلل أمان التطبيق طرح سؤال حول عملية التطوير. تعد SDLC (Secure Development LifeCycle) أول كلمة طنانة تظهر عند القراءة حول أمان التطبيق. باختصار ، الهدف من هذه الإجراءات هو التأكد من مراعاة اعتبارات أمان النظام في كل مرحلة من مراحل التطوير. في هذه الحالة ، لا يكون متخصص الأمان دائمًا يشارك في أداء مهام محددة ، في بعض الأحيان يمكنك التفويض لأعضاء الفريق الآخرين. بعد كل شيء ، كلما وجدت مشكلة ، كلما كان أرخص حلها.
العقل البشري لا يزال لا غنى عنه في العثور على نقاط الضعف
- يمكن العثور على مشاكل المنتج على مستوى المواصفات ، ومناقشته ، والنموذج الأولي ، والرسم ، عندما لا يكون هناك سطر واحد من الكود. لكن القضايا الأمنية في أي مرحلة أصبح من الممكن العثور عليها؟ وهل يمكن العثور عليها حتى قبل كتابة الكود؟
- بالطبع ، لأن هناك مشاكل مرتبطة مباشرة بكيفية صياغة المتطلبات. اسمحوا لي أن أعطيك مثالا وحشي. يمكنك إنشاء نموذج تسجيل دخول ، ويخبرك المصمم: "ودع مستخدمينا يقولون إنهم لم يقوموا فقط بإدخال كلمة المرور غير الصحيحة ، لكنهم ارتكبوا خطأ في الحرف الأخير من كلمة المرور الخاصة بهم." أي أن صياغة الشرط قد تكون غير آمنة بطبيعتها.
وأيضًا ، في مرحلة المعارف التقليدية ، يمكن افتراض أن النظام سيكون عرضة لبعض نقاط الضعف ، ويجب تنفيذ بعض آليات الحماية. إذا كنت تأخذ نفس النموذج على الموقع ، فستحتاج بالتأكيد إلى إنشاء اختبار لمنع التخمين بكلمة المرور. لذلك ، ينبغي ذكر هذه النقاط في تطوير الهندسة المعمارية.
- كم مرة يتم تضمين اختبار الأمان في عمليات CI / CD ، وهل هو صعب؟ هذا هو ، من أجل أن تكون قادرة على "تمزيق" أي خط أنابيب في Jenkins أو TeamCity ، وكانت هناك مرحلة منفصلة حيث يتم تشغيل اختبارات الأمان. كيف الحقيقي هو؟
- هناك مبادئ توجيهية على نفس SDLC ، وهناك متطلبات المنظمين. وفقًا لذلك ، تقوم الشركات التي لديها عملية تطوير ناضجة بتنفيذها. هناك أدوات لأتمتة جزء من العملية ، لكن نسبة الجهد والنتيجة تعتمد على طبيعة المشروع وعلى أي مرحلة من التطوير بدأت هذه التقنيات في تنفيذها.
إذا كان التطبيق مكتوبًا من نقطة الصفر ، فيمكنك عرض استخدام محلل ثابت لتجنب الإرشادات المشبوهة في التعليمات البرمجية. وإذا كتبت الكود قبل 10 سنوات ، وجئت إلى هناك مع أداتك للحصول على أموال مجنونة ، فستجد بالطبع القليل.
تواجه جميع الأدوات التلقائية مشكلة أنها لا تعرف كيف يعمل النظام. إذا كان يمكن عزل مكون فردي من النظام ، فيمكن اختباره بأدوات جاهزة. ولكن في نظام به العديد من التبعيات ، يمكن أن تفقد الماسحات الضوئية الآلية معلومات قيمة.
تحليلات الأمن في شركات أخرى
- ما هي الشركة أو أي مشروع فردي ، في رأيك ، هو الرائد في تحليلات أمان التطبيقات ، بناءً على خطابات الشركة وعروض المؤتمرات؟
- توصلت مايكروسوفت إلى تنفيذ SDLC الذي أصبح الشريعة. لكن إليكم كيفية عملهم عند أدنى مستوى ، والأدوات المستخدمة ، لا أعرف.
يكتب Facebook الكثير عن كيفية ترتيب كل شيء تقنيًا: كيف يقومون بمسح الرمز ضوئيًا والعثور على نقاط الضعف في أنظمة العمل ، إلخ. بعض أدوات Facebook هي مشاريع مفتوحة المصدر ، حتى تتمكن من التنقيب بشكل أعمق في أحشاءها.
إذا أخذنا الشركات الروسية ، فإن سبيربنك تحدث بشكل مثير للاهتمام حول كيفية إضفاء الطابع الرسمي على SDLC ، وثق العملية. على الرغم من أن فريق أمان التطبيق الخاص بهم كبير إلى حد ما ، إلا أنه لا يكفي للعديد من المطورين. لذلك ، يقومون بتثقيف أبطال الأمن في فرق ، ووضع بعض المعرفة حول الأمن في رؤوسهم ، وفي هذه الحالة يمكن للأبطال رفع علم أحمر.
يتحدث ياندكس في مؤتمرات حول أشياء رائعة مثل "كيفية اختراق متصفح".
- هل من الواقعي أن اختبار بعد المؤتمر ، حيث سمع تقريرا عن التهديدات والأدوات ، سوف يكون لها تأثير كبير بعد تنفيذها؟ على سبيل المثال ، ستشتري شركة ماسحة ضوئية بمبلغ 10،000 دولار تبحث عن ثقوب في خط أنابيب جينكينز. أم أنه من المهم معرفة آليات استغلال الثغرات الأمنية من أجل تنفيذ بعض الأشياء؟
- لا يمكنك شراء ماسحة ضوئية بقيمة 10 آلاف دولار (يضحك) . إذا كنا نتحدث عن البحث عن الثغرات الأمنية ، فسوف يتعلق الأمر باختبار سيناريوهات معينة. تؤخذ السيناريوهات من مجموعات المعرفة العامة.
على سبيل المثال ، ينشر OWASP (مشروع أمان تطبيق الويب المفتوح) أدلة حول كيفية إجراء اختبار الأمان ومراجعات التعليمات البرمجية وما إلى ذلك. على سبيل المثال ، في OWASP Application Security Verification Standard ، تتم كتابته حول كل ما يلزم اختباره. لقراءة المستند ، ليست هناك حاجة إلى معرفة خاصة ، وهو ما يكفي لمعرفة تطبيقات الويب ، لذلك يمكن لأي اختبار اختباره.
الأوراق القياسية والغش كافية لتشغيل الاختبارات اليدوية. تقول أنواع الثغرات الموجودة وكيفية البحث عنها. لا يمكن إجراء بعض الاختبارات بواسطة الماسحات الضوئية القياسية بحكم التعريف: على سبيل المثال ، تلك المتعلقة بفحص منطق العمل.
من ناحية أخرى ، إذا كنت بحاجة إلى العثور على XSS ، فأنت بحاجة إلى إضافة علامة اقتباس أو شريحة أو ما إلى ذلك في كل معلمة تم تغييرها ، وإذا كان هناك 100 مليون معلمة في النظام ، فإن المهمة لم تعد ممكنة. لكن الأدوات الآلية ستعمل بشكل جيد معها.
ولكن عند بدء تشغيل الماسح الضوئي ، قد يكون هناك ثلاثة سيناريوهات:
- أصدرت الأداة تقريرًا يحتوي على الكثير من الأخطاء القابلة للتكرار وإيجابية خاطئة قليلاً (مثالية ، لكن من غير المحتمل).
- يحتوي التقرير على 20 ألف اكتشاف ، منها حوالي 1٪ صحيحة. لذلك ، عليك الجلوس وتحديد ما إذا كانت المشاكل الحقيقية.
- لم تتمكن الأداة من فهم شيء ما في النظام ، لذلك أصدرت تقريرًا يكون فيه كل شيء على ما يرام ، لكنه ليس كذلك. على سبيل المثال ، لم أستطع تجميع الشفرة لأنني لم أتمكن من العثور على المكتبة. أم أنه ماسح ثغرات أمنية قام بتقديم 10 طلبات ، وواجه مشكلة مكافحة الفيضانات ، ولم يتلق استجابة من الخادم فيما يتعلق بطلبات المليون المتبقية.
لذلك ، أعتقد أنه من المهم أن نفهم مع ذلك أن الماسحة الضوئية "تحت الغطاء" لتحديد الأداة المناسبة للمهمة التي يجري حلها وتقييم النتيجة بشكل كافٍ.
سيقوم ألكساندر بتطوير موضوع الاختيار الصحيح وضبط الأدوات في تقريره عن Heisenbug. ستتحدث هناك عن تطبيق وتخصيص SAST-solutions SonarQube و Find Security Bugs للبحث عن نقاط الضعف في مشروعها. ما هي الميزات التي توفرها هذه الأدوات "خارج الصندوق"؟ وكيف لتوسيع وظائفها من تلقاء نفسها؟ على سبيل المثال ، سينظر المتحدث في نقاط الضعف في XSS و IDOR.
سيعقد المؤتمر 5-6 ديسمبر في موسكو.