لا يوجد برنامج بدون أخطاء ، أليس كذلك؟ في حين أن هذا شعور شائع ، فإننا نفترض افتراضات تعتمد على فرضية أن البرنامج لا يحتوي على أخطاء في حياتنا الرقمية اليومية. نحن نثق في موفري الهوية (IDPs) للحصول على المصادقة الصحيحة ، وأنظمة التشغيل للامتثال التام لمواصفاتهم ، والمعاملات المالية لتعمل دائمًا على النحو المنشود. بشكل أكثر وضوحًا ، نحن نثق بالبرنامج مع سلامتنا الجسدية من خلال الذهاب على متن الطائراتقيادة السيارة التي تصحح بشكل فعال تمسكنا بالممرات المرورية أو بعدنا عن السيارة التي أمامنا ، أو الخضوع لعمليات جراحية معينة. ما الذي يجعل هذا ممكنا؟ أو بعبارة أخرى ، لماذا لا تسقط الطائرات من السماء بسبب البرامج السيئة؟
يقترض ضمان جودة البرمجيات من الأدوات العلمية والهندسية. تتمثل إحدى طرق ضمان جودة البرامج وتحسينها في الإعلان عنها وإعطاء أكبر عدد ممكن من الأشخاص حافزًا لمحاولة كسرها.
طريقة أخرى هي استخدام أنماط التصميم أو أطر العمارة الجيدة المتجذرة في الهندسة. على سبيل المثال ، في حين أنه لا يمكن وضع كل مشروع برمجي تحت نفس المستوى من التدقيق مثل Linux kernel ، الذي كان قيد الفحص منذ عقود ، يمكن لمشاريع البرامج أن تفتح كود المصدر لدعوة التدقيق أو إرسال تعليمات برمجية للتدقيق على أمل الحصول على بعض الضمانات الأمنية.
وبالطبع ، هناك اختبارات. سواء أكان الاختبار ثابتًا أو ديناميكيًا أو في الوقت الفعلي ، تم إجراؤه بواسطة المطور أو بواسطة فريق متخصص ، فإن الاختبار يمثل جزءًا رئيسيًا من تطوير البرامج. مع البرامج الهامة ، يكون الاختبار عادةً مشروعًا منفصلاً تمامًا يتم التعامل معه بواسطة فريق منفصل يتمتع بخبرة محددة.
الاختبار جيد ، لكنه لا يدعي أنه شامل. لا توجد ضمانات بالعثور على جميع الأخطاء لأننا لا نعرف الأخطاء التي لا نعرف عنها. هل وجدنا بالفعل 99٪ من أخطاء Linux kernel الموجودة هناك؟ 50٪؟ 10٪؟
الادعاء "المطلق"
يبحث مجال البحث عن الأساليب الرسمية في طرق للتأكد من عدم وجود أخطاء في برنامج معين ، مثل سمسار البورصة أو سلطة إصدار الشهادات. الفكرة الأساسية هي ترجمة البرامج إلى رياضيات ، حيث يتم تعريف كل شيء جيدًا ، ثم إنشاء دليل فعلي على أن البرنامج يعمل بدون أخطاء. بهذه الطريقة ، يمكنك التأكد من أن برنامجك خالٍ من الأخطاء بنفس الطريقة التي يمكنك التأكد من أن كل رقم يمكن أن يتحلل إلى مضاعفة الأعداد الأولية. (لاحظ أنني لا أحدد ما هو الخطأ. سيثبت هذا أنه مشكلة ، كما سنرى لاحقًا.)
لطالما استُخدمت تقنيات الطريقة الرسمية للبرامج الهامة ، لكنها كانت تتطلب جهدًا شديدًا في الحوسبة والجهد ، ولذا فهي تُطبق فقط على أجزاء صغيرة من البرامج ، مثل جزء محدود من البرامج الثابتة للشرائح أو بروتوكول المصادقة. في السنوات الأخيرة ، تقدم مبررات نظرية مثل Z3 و صياح الديك جعلت من الممكن تطبيق هذه التكنولوجيا في سياق أكبر. هناك الآن التحقق رسميا لغات البرمجة, أنظمة التشغيلو المجمعين مضمونة 100٪ للعمل وفقًا لمواصفاتها. لا يزال تطبيق هذه التقنيات يتطلب خبرة متقدمة وقدرًا كبيرًا من قوة الحوسبة ، مما يجعلها باهظة التكلفة بالنسبة لمعظم المؤسسات.
يقوم مقدمو الخدمات السحابية الرئيسيون بإجراء تحقق رسمي من مكدساتهم الأساسية للوصول إلى مستويات عالية من ضمان الأمان. أمازون و مایکروسافت خصصت مجموعات بحثية تعمل مع فرق هندسية لدمج طرق التحقق الرسمية في البنية التحتية الحيوية ، مثل التخزين أو الشبكات. الامثله تشمل AWS S3 و EBS و أزور بلوكتشين. لكن الحقيقة المثيرة للاهتمام حقًا هي أنه في السنوات القليلة الماضية ، كان مقدمو الخدمات السحابية كذلك يحاول أن سلعة التحقق الرسمي لبيعها لعملائها.
حل حاسم خطأ في التكوين؟
في العام الماضي ، أصدرت AWS ميزتين تستفيدان من التحقق الرسمي لمعالجة المشكلات التي لطالما ابتليت بها العملاء ، وهما الشبكة و التهيئة الخاطئة لإدارة الهوية والوصول (IAM)س. يعد الوصول إلى الشبكة وتكوينات IAM معقدة ، حتى بالنسبة لحساب واحد ، ويزداد هذا التعقيد بشكل كبير في مؤسسة كبيرة مع اتخاذ القرارات والحوكمة الموزعة. تتعامل AWS مع ذلك من خلال منح عملائها عناصر تحكم بسيطة - مثل "يجب ألا تتعرض حاويات S3 للإنترنت" أو "يجب أن تمر حركة مرور الإنترنت إلى مثيلات EC2 عبر جدار حماية" - وتضمن تطبيقها في كل سيناريو تكوين ممكن.
AWS ليست أول من يعالج مشكلة التهيئة الخاطئة ، حتى بالنسبة للمشكلات الخاصة بـ AWS مثل فتح دلاء S3. لقد عالج موردو إدارة وضع أمان السحابة (CSPM) هذه المشكلة لفترة من الوقت الآن ، حيث قاموا بتحليل تكوين قناة المنفذ الافتراضي (VPC) وأدوار IAM وتحديد الحالات التي تكون فيها الامتيازات منخفضة للغاية ، ولا يتم استخدام ميزات الأمان بشكل صحيح ، ويمكن كشف البيانات الى الانترنت. إذا ما الجديد؟
حسنًا ، هذا هو المكان الذي يأتي فيه الضمان المطلق حل CSPM يعمل عن طريق إنشاء قائمة معروفة - سيئة أو معروفة - جيدة من التكوينات الخاطئة ، وأحيانًا إضافة سياق من بيئتك ، وإنتاج النتائج وفقًا لذلك. يعمل محللو الشبكة و IAM من خلال فحص كل IAM أو طلب شبكة محتمل والتأكد من أنها لن تؤدي إلى وصول غير مرغوب فيه وفقًا لمواصفاتك (مثل "لا يوجد اتصال بالإنترنت"). يكمن الاختلاف في الضمانات حول السلبيات الكاذبة.
بينما تدعي AWS أنه لا توجد طريقة فقدها أي شيء ، يقول بائعو CSPM إنهم يبحثون دائمًا عن تكوينات خاطئة جديدة للفهرسة والكشف ، وهو اعتراف بأنهم لم يكتشفوا هذه التكوينات الخاطئة من قبل.
بعض عيوب التحقق الرسمي
يعد التحقق الرسمي أمرًا رائعًا للعثور على مشكلات محددة جيدًا ، مثل مشكلات أمان الذاكرة. ومع ذلك ، تصبح الأمور صعبة عند محاولة العثور على أخطاء منطقية لأن تلك تتطلب تحديد ما يفترض أن تفعله الشفرة بالفعل ، وهو بالضبط ما تفعله الشفرة نفسها.
لسبب واحد ، يتطلب التحقق الرسمي تحديد أهداف محددة جيدًا. في حين أن بعض الأهداف ، مثل منع الوصول إلى الإنترنت ، تبدو بسيطة بما فيه الكفاية ، إلا أنها في الواقع ليست كذلك. وثائق محلل AWS IAM لها قسم كامل تعريف ما تعنيه كلمة "عام" ، وهي مليئة بالمحاذير. الضمانات التي يقدمها جيدة فقط مثل الادعاءات الرياضية التي قام بترميزها.
هناك أيضًا مسألة التغطية. لا يغطي محللو AWS سوى عدد قليل من خدمات AWS الرئيسية. إذا قمت بتوجيه حركة المرور إلى شبكتك عبر قناة اتصال صادرة ، فلن يعرف المحلل ذلك. إذا كان لدى بعض الخدمات حق الوصول إلى دورين من أدوار IAM ويمكنهما الجمع بينهما للقراءة من مستودع عام سري والكتابة إلى أحد الأدوار العامة ، فلن يعرف المحلل. ومع ذلك ، في بعض المجموعات الفرعية المحددة جيدًا لمشكلة التهيئة الخاطئة ، يوفر التحقق الرسمي ضمانات أقوى من أي وقت مضى.
بالعودة إلى سؤال الميزة النسبية المطروح أعلاه ، يتمثل الاختلاف في أن IAM ومحلل الشبكة يدعيان أن قائمة المشكلات التي تم اكتشافها شاملة ، بينما تدعي CSPM أن قائمتها تغطي كل التهيئة الخاطئة المعروفة اليوم. إليكم السؤال الرئيسي: هل يجب أن تهتم؟
هل يجب أن نهتم بالضمانات المطلقة؟
ضع في اعتبارك السيناريو التالي. أنت تمتلك CSPM وتنظر إلى شبكة AWS ومحلل IAM. بمقارنة نتائج الاثنين ، تدرك أنهما حددا المشكلات نفسها بالضبط. بعد بعض الجهد ، تقوم بإصلاح كل مشكلة في تلك القائمة. بالاعتماد فقط على CSPM الخاص بك ، ستشعر أنك في مكان جيد الآن ويمكنك تخصيص موارد أمنية في مكان آخر. من خلال إضافة أدوات تحليل AWS إلى المزيج ، فأنت تعلم الآن - بضمان AWS - أنك في مكان جيد. هل هذه هي نفس النتائج؟
حتى إذا أهملنا تحذير التحقق الرسمي وافترضنا أنه يلتقط 100٪ من المشكلات ، فإن قياس الفوائد على الخدمات القائمة على الاكتشاف مثل CSPM سيكون تمرينًا لكل مؤسسة فردية لديها استعدادها للمخاطر الأمنية. قد يجد البعض هذه الضمانات المطلقة رائدة ، بينما قد يلتزم البعض الآخر بالضوابط الحالية.
هذه الأسئلة ليست خاصة بـ CSPM. يمكن إجراء نفس المقارنات لأدوات اختبار أمان تطبيقات الويب SAST / DAST / IAST والبرامج التي تم التحقق منها رسميًا ، على سبيل المثال لا الحصر.
بغض النظر عن اختيارات المؤسسة الفردية ، فإن أحد الآثار الجانبية المثيرة لهذه التكنولوجيا الجديدة سيكون وسيلة مستقلة لبدء قياس المعدلات السلبية الخاطئة لحلول الأمان ، ودفع البائعين ليكونوا أفضل وتزويدهم بأدلة واضحة حيث يحتاجون إلى التحسين. هذا في حد ذاته هو مساهمة هائلة في صناعة الأمن السيبراني.
