SD3
SD3 - منهجية فريق SWI في حماية تطبيقات وأنظمة مايكروسوفت
ذكر الكاتبين ميشيل و ديفيد في كتاب Writing Secure Code المنهجية التي يتبعها فريق Secure Windows Initiative team في شركة Microsoft لضمان أمان التطبيقات التي تقوم الشركة بإنتاجها. الفريق يتبع منهجية أسماها: SD3 والتي تحمل المعنى الآتي:
Secure by Design, by Default, and in Deployment
أي منهجية التطبيقات المحمية خلال مرحلة تصميمها، ومحمية في أصلها، وعند نشرها.
الحماية خلال مرحلة التصميم Secure by Design:
ملاحظة: إذا لا تعلم ما المقصود بمرحلة التصميم خذ نظرة على هذا المقطع أولًا.
في هذه المنهجية يعتبر الفريق "الحماية" كأحد أهم العناصر خلال عملية بناء النُظم، وليس بعد الانتهاء من بناء النظام. لخّص الكاتبين أيضًا بعض من الممارسات أو النصائح التي يمكن إتباعها خلال هذه المرحلة مثل:
- تقديم التدريب المتعلق بمفاهيم الحماية لكل شخص له دور في بناء النظام.
- اتباع المعايير العالمية المتعلقة بالحماية خلال عملية بناء الأنظمة (تستطيع الاطلاع على هذه المعايير في الملاحق المرفقة في آخر الكتاب)
- التأكد بأن المعايير المُتّبعة ذات فائدة في بناء النظام أو التطبيق، على سبيل المثال ليست معايير قديمة لا تتوافق مع التقنيات الحديثة، وكما أن الثغرات الأمنية مُتجددة فيجب تطبيق المعايير التي تتناسب مع طبيعة النظام وتقنياته.
- إصلاح جميع الـ Bugs (المتعلقة بالحماية تحديدًا) التي تظهر خلال عملية التصميم أولًا بأول وعدم مراكمتها حتى الانتهاء من تصميم النظام حيث أنها ستصبح مهمة معقدة جدًا حينها بسبب نمو النظام وتفرّع خصائصه و وظائفه.
- كتابة كود بسيط ونظيف :)، فإن كانت الأكواد معقدة جدًا ستكون عملية تصحيح الأخطاء أعقد غالبًا (هذه دورة في كتابة الكود النظيف في لغة جافا إذا كنت مهتم في هذا الشأن).
- آخرًا، بعد الإنتهاء من تصميم النظام وبرمجته بشكل كامل، يقترح الكاتب البدء في إجراء إختبارات الإختراق Penetration Testing
جعل النظام محمي بشكل افتراضي Secure by Default:
ملاحظة متعلقة بترجمة المعنى: ترجمتي لهذا المعنى أرى أنها ركيكة أو مختلفة بعض الشيء عن المعنى الحقيقي المذكور في الكتاب، لكن بعد بحث هذا اللي طلع معاي للأسف :)، لذلك إذا كنت تملك تعريف أكثر مُواءَمة فضلًا شاركه معي على حسابي حتى أقوم بتحديث المعنى في هذه التدوينة (الحقوق محفوظة طبعًا!).
المقصود في هذه المنهجية هو بناء نظام محمي بشكل إفتراضي، أو بمعنى آخر يكون التطبيق محمي ضد أشهر الهجمات، وبالإمكان إتباع بعض الممارسات المساعدة في تحقيق هذا مثل:
- إذا كان النظام يحتوي على وظائف أو خصائص عدّة، فيجب فقط تفعيل الخصائص أو الوظائف التي يقوم باستخدامها مستخدمي النظام، ويجب تعطيل جميع الوظائف غير المستخدمة.
- تطبيق مفهوم "الصلاحية الأقل" أو ما يعرف بـ Least Privilege في النظام، والمقصود به إعطاء كل مستخدم فقط الصلاحيات التي يحتاجها لإتمام مهامه في النظام.
- توفير الحماية المناسبة للمصادر، والمقصود بالمصادر هنا هو البيانات الحساسة الخاصة بالنظام.
حماية النظام عند نشره Secure in Deployment:
حماية النظام خلال مرحلة تصميمه، أو بناء نظام محمي ضد أشهر الهجمات ليس بكافي، لابد من استكمال عملية حماية النظام حتى بعد نشره، لاسيما أن الثغرات الأمنية متجددة بشكل شبه يومي كما ذكرنا سلفًا، اقترح الكاتبين بعض الممارسات التي يمكن اتباعها لضمان الحماية خلال نشر النظام مثل :
- التأكد بأن النظام يوفر وسيلة تُمكّن مُدراء النظام من التحكم بخصائص الحماية، على سبيل المثال واجهة يمكن من خلالها إدارة الخصائص المرتبطة بالحماية والصلاحيات في النظام
- التأكد بأن النظام أيضًا يوفر وسيلة لتتبع عمليات الـ patching ، أو تتبع عمليات تحديث النظام وإصلاح مشاكله، فيستطيع مدير النظام معرفة الإصدار الحالي الخاص بالنظام، وفي حالة وجود ثغرة أمنية يكون بإمكان مدير النظام التحقق من هذه التحديثات وتحديد إذا ما كانت هذه الثغرة بسبب تحديث أُجري مؤخرًا على النظام.
- تقديم المعلومات الكافية لمستخدمي النظام وتثقيفهم حول آلية استخدام النظام بطريقة آمنه، وبالإمكان تطبيق هذا المفهوم من خلال توفير "المساعدة المباشرة" لمستخدمي النظام أو من خلال توفير documentation أو مصادر يلجأ لها مستخدمي النظام لأجل إتمام مهامهم في النظام.
المرجع:
كتاب: Writing Secure Code
فصل: Chapter 3. Security Principles to Live By
الموضوع: SD3: Secure by Design, by Default, and in Deployment
صفحة: 88