إطار عمل لدمج أمن التطبيقات في هندسة البرمجيات (FIASSE)

ملاحظة: هذا المستودع عمل مستمر. المساهمات مرحّب بها!

نظرة عامة

باختصار: يُرجى قراءة DOC. استكشف موقع FIASSE. قم بزيارة GitHub Discussions للمساهمة.

يحتوي هذا المستودع على موارد ومواد لإطار عمل OWASP لدمج أمن التطبيقات في هندسة البرمجيات (FIASSE). FIASSE (تُنطق /feiz/ مثل 'phase') هو إطار عمل مستقل عن البائعين يعزز نهجًا مبدئيًا يتمحور حول المطور لبناء برمجيات قابلة للتأمين. وهو يدرك أن الأمن عملية ديناميكية ومستمرة مثل التطوير. ويقدّم نموذج هندسة البرمجيات القابلة للتأمين (SSEM) بوصفه لغة تصميم مشتركة تستخدم مصطلحات هندسة البرمجيات الراسخة لدمج الأمن في معمارية البرمجيات وتصميمها وهندستها من خلال تضمين الأمن في المبادئ التي تشكّل الشيفرة نفسها. ويمكّن الإطار فرق التطوير من إضافة قيمة حوسبية بمرونة مع تقليل احتمالية التأثير الجوهري من الأحداث السيبرانية طوال عمر الشيفرة.

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

الغرض

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

كيف يختلف؟

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

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

القيم الأساسية

يسترشد FIASSE بأربع قيم أساسية. كل منها يعبّر عن تفضيل نسبي: لكلا الجانبين قيمة، لكن عندما يجب الاختيار، يفضّل FIASSE الجانب الأيسر.

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

المبادئ الرئيسية

• النموذج القابل للتأمين (Securable Paradigm): لا توجد حالة ثابتة تُسمى "آمن". فالنظام الذي يُعلن أنه آمن اليوم قد يكون عرضة للخطر غدًا. يعيد FIASSE توجيه الهدف الهندسي من "هل هو آمن؟" إلى "هل بُني بحيث يمكن الحفاظ على الأمن؟" من خلال المرونة التكيفية، والأمن التطوري، والتحسين المستمر.
• إضافة قيمة حوسبية بمرونة (Resiliently Add Computing Value): التوجيه الأساسي لهندسة البرمجيات في سياق الأعمال. يجب أن تلبي البرمجيات المتطلبات الوظيفية مع الحفاظ على الخصائص القابلة للتأمين التي تمكنها من تحمل التغيير والضغط والهجوم الذي يتبع كل تغيير.
• مهمة الأمن: تقليل الأثر الجوهري (Security Mission: Reducing Material Impact): مهمة الأمن هي تقليل احتمالية الأثر الجوهري لحدث سيبراني. إن القضاء التام على الاختراقات ليس هدفًا تجاريًا عمليًا، لذا يجب أن تتوافق استراتيجيات الأمن مع أهداف الأعمال وقدرتها على تحمل المخاطر.
• العلاقة بين الجودة والأمن (The Quality-Security Relationship): لا يمكن أن يتجاوز الأمن جودة البرمجيات. فالخصائص التي تجعل البرمجيات سهلة الفهم والتغيير والاختبار والمراقبة هي نفس الخصائص التي تجعل تأمينها ممكنًا. الاستثمار في جودة الهندسة هو استثمار في الأمن.
• الأمن المتمحور حول المطور (Developer-Centric Security): تمكين مهندسي البرمجيات من بناء أنظمة قابلة للتأمين باستخدام مبادئ هندسة البرمجيات المألوفة، بدلاً من مطالبتهم بتبني عقلية مختبِر الاختراق.
• SSEM كلغة تصميم مشتركة (SSEM as a Common Design Language): استخدام مصطلحات هندسة البرمجيات الراسخة (مثل قابلية التحليل، وقابلية التعديل، وقابلية الاختبار) لتعريف سمات الأمن ومناقشتها. وهذا يجعل الأمن في متناول المطورين ويمنح متخصصي الأمن أساسًا مشتركًا للتقييم.
• مواءمة الأمن مع أهداف التطوير والأعمال (Aligning Security with Development and Business Goals): الأمن والتطوير متكاملان وليسا متخاصمين. يشارك AppSec مبكرًا في دورة حياة تطوير البرمجيات (SDLC)، لا سيما أثناء جمع المتطلبات وتخطيط الميزات، بحيث تكون التوقعات واضحة قبل كتابة الكود.
• مبدأ الشفافية (The Transparency Principle): تُصمم الأنظمة بحيث يستطيع الأطراف المصرح لهم فهم الحالة الداخلية والسلوك. تُبنى السجلات المنظمة وأدوات القياس ومسارات التدقيق داخل الكود بدلاً من توفيرها بواسطة الأدوات الخارجية وحدها.
• مبدأ أقل مفاجأة (The Principle of Least Astonishment): تتصرف الأنظمة بطرق بديهية وقابلة للتنبؤ بالنسبة للمستخدمين والمطورين والمسؤولين. فالقابلية للتنبؤ تساعد في التحليل، وتقلل العبء المعرفي، وتجعل حدود الثقة واضحة.
• المتطلبات كمواطن من الدرجة الأولى في AppSec (Requirements as a First-Class Citizen in AppSec): تُسلَّم ميزات الأمن وسيناريوهات التهديد ومعايير قبول الأمن من خلال عملية المتطلبات. غالبًا ما تعود الثغرات إلى توقع لم يُحدَّد قط، لذا فإن تلك الفجوة تنتمي إلى عملية المتطلبات.

مبادئ الهندسة

يقدم القسم 4 من الإطار للمطورين مبادئ تنطبق مباشرة على مستوى الكود:

• مبدأ التحكم في الحدود (The Boundary Control Principle): المرونة داخل النظام هي أصل هندسي يجب الحفاظ عليه. أما التحكم عند كل حد ثقة فهو متطلب أمني يجب فرضه.
• التعامل القانوني مع المدخلات (Canonical Input Handling): قم بتقنين المدخلات والتحقق منها وتنقيتها عند نقطة الدخول. يقوم مبدأ التحليل القانوني (Canonical Parsing Principle) بتحليل المدخلات الخارجية إلى نوع داخلي قانوني عند الحدود ويفشل بشكل مغلق عندما لا ينجح التحليل.
• مبدأ السلامة المعزولة (The Isolated Integrity Principle): تُشتق القيم الحرجة للسلامة مثل الأسعار والأدوار وحالة الكائنات من مصادر موثوقة على جانب الخادم. ولا تُقبل أبدًا مباشرة من العميل.
• البرمجة المرنة (Resilient Coding): تفرض ممارسات البرمجة الدفاعية تنفيذًا قابلًا للتنبؤ. وتشمل هذه الكتابة القوية، والتحقق من المدخلات عند حدود الثقة، وترميز المخرجات، ومعالجة الأخطاء الشاملة، وإدارة الموارد الآمنة، والفشل الرشيق والآمن، وأقل امتياز على مستوى الكود.
• رعاية التبعيات (Dependency Stewardship): طبّق سمات SSEM عند اختيار التبعيات ودمجها ومراقبتها وصيانتها طوال عمر العلاقة.

نموذج هندسة البرمجيات القابلة للتأمين (SSEM)

يحدد SSEM السمات التي تجعل البرمجيات قابلة للتأمين. تضع الفرق أهدافًا لكل سمة، وتقيّم الأنظمة وفقًا لها، وتحسّن بشكل تدريجي. تُنظَّم السمات في ثلاث فئات:

قابلية الصيانة	الموثوقية الأمنية	الاعتمادية
قابلية التحليل	السرية	التوافر
قابلية التعديل	المساءلة	السلامة
قابلية الاختبار	الأصالة	المرونة
قابلية المراقبة

لا يحتوي SSEM على سمة التفويض بحكم التصميم. التفويض هو ميزة أمنية تُجمَع كمتطلب وتُنفَّذ وفقًا لمعايير القبول. السمات المذكورة أعلاه هي ما يجعل هذه الميزة قابلة للتأمين. يصف الملحق A من الإطار منهجيات قياس كل سمة.

محتويات المستودع