أنت حالياً تتصفح نسخة خفيفة من المنتدى .
مشاهدة نسخة كاملة مع جميع الأشكال الجمالية .
كاتب الموضوع : أحمد جمال
بسم الله الرحمن الرحيم .
السلام عليكم ورحمة الله وبركاته .
في العدد الأخير من مجلة MSDN كتب Michael Howard مقالاً بعنوان :
Lessons Learned from Five Years of Building More Secure Software
سنحاول نقل ترجمة مختصرة لها هنا ، ولمن يريد المقالة الأصلية فهذا هو الرابط :
http://msdn.microsoft.com/msdnmag/issues/07/11/Lessons/
بداية يقول : منذ خمسة سنوات ، أرسل بيل جيتس رسالة لموظفيه يشرح لهم فيها أهمية بناء تطبيقات على درجة عالية من الحماية والأمان ، ومنذ ذلك التاريخ ، عمل العديد من الأشخاص في شركة مايكروسوفت على بناء تطبيقات أكثر أمناً وحماية
يعود ليقول مرة أخرى ، أن مجال الحماية ليس مجالاً ثابتاً ، بل هو باختصار استمرار المهاجمين في الهجوم والمدافعين في الدفاع مع استمرار تعلم كل طرف من الآخر ، لذا عليه (الكاتب) كمدافع أن يظل يتعلم من أخطاءه ليحمي مستخدمية لاحقاً .
الدرس الأول : إنه ليس فقط الكود It's Not Just the Code
في صناعة البرمجيات أو بالأحرى صناعة البرمجيات المتقدمة ، فإن الأمر لا يقتصر على كتابة الكود قدر ما يعتمد على فهم الكود بطريقة صحيحة ، إذا استمررت في محاولة فقط ايجاد الثغرات الأمنية في الكود سوف تغيب عن باقي قائمة المتطلبات الأمنية أو الثغرات الموجودة ، ولعل هذا واحد من الأسباب التي دفعت مايكروسوفت لاعتماد threat modeling and attack surface analysis كجزء من دورة حيان الأمان في تطبيقات مايكروسوفت ، يعتبر threat modeling تقنية تحليل تستخدم لمعرفة نقاط الضعف في المنتج ، أما ال attack surface analysis فيركز على أي اجزاء البرنامج سوف تكون معروضة لمستخدمين غير مؤتمنين ، يمكنك معرفة المزيد من خلال هذا الرابط :
msdn.microsoft.com/msdnmag/issues/04/11/AttackSurface
الدرس المستفاد : إنه من الضروري بناء threat models لكشف ضعف التصميم ولمعرفة ال attack surface ، أنت بحاجة للتأكد من أن أغلب النقاط محمية وأن سطح الهجوم attack surface صغير قدر الإمكان .
الدرس الثاني : Fix Old Code First أصلح الكود القديم أولاً .
عندما يتعلق الأمر بمراجعة الكود ، أفضل تصنيف الكود بناء على نقاط الضعف فيه ، إن الأولوية الأولى دوماً هي الكود القديم ، حيث أنه غالباً ما يكون خاضعاً لقدر أقل من اختبارات الأمان ، حيث أن التهديدات تتطور مع الزمن وربما لا يكون الكود القديم من برنامجك مواكباً لها بشكل صحيح ، اضف إلى ذلك أن الخبرة الدفاعية تتطور مع الزمن والكود القديم مهما كان بني في فترة أضعف من ناحية الخبرات البرمجية الدفاعية .
لذا فنصيحتي دائماً أن تتم مراجعة الكود القديم يدوياً وهذه هي السياسة التي تنتهجها مايكروسوفت ، ولهذا فإن تصنيف الكود لدينا لا يعتمد على عدد الأكواد أو تعقيدها او عدد الأسطر ، قدر ما يعنينا عمر هذا الكود .
الدرس المستفاد : قم بترتيب أكواد برنامجك بناء على عمر الكود ، ومن ثم قم بمراجعتهم يدوياً إبتداء من الكود الأقدم .
الدرس الثالث : Deprecate! Eliminate! Eradicate! استنكر ! أزل ! استأصل !
أحياناً ما لا تكون ميزة ما أو جزئية في البرنامج آمنة هذه الأيام قدر ما كانت آمنة منذ عدة سنوات ، ربما لا يتعلق الأمر بنقاط الضعف ولكن بتغير بيئة العمل على الأجهزة الشخصية اليوم .
واحد من الأمثلة الجيدة على ذلك هي خدمة Alerter service الموجودة في ويندوز ، هذه الخدمة بدأت تصنف لاحقاً على أنها Spam لذا تم تعطيلها في XP Service Pack 2 حتى تم الغاءها تماماً في Vista .
في العديد من الحالات ستجد مايكروسوفت تقوم بازالة بعض المميزات رغم اعتماد المستخدمين عليها ، يتعلق الأمر بالموازنة بين الفائدة المترتبة والخطر الناتج عن هذه الميزة .
الدرس المستفاد : صنف المميزات القديمة التي ربما تكون أضعف في مستوى الأمان وتسبب لك خروقات أمنية على المدى البعيد ، ربما تكون الخطوة الأولى في تعطيل هذه الخدمة ، في الاصدار اللاحق قم بازالتها مع ايجادها على شكل ملف للتحميل على الإنترنت لأولئك المستخدمين الذين يعتمدون عليها كلياً ، في الخطوة الأخيرة قم برفع الدعم عنها ، أهم ما في الأمر ألا توقف ميزة ما مرة واحدة ومباشرة .
نكمل باقي ترجمة المقال لاحقاً إن شاء الله تعالى .