توسعه امن نرم‌افزار

1. بسم الله الرحمن الرحیم توسعه امن نرم‌افزار رسول جلیلی زمستان 91 فصل چهارم

2. تحلیل ریسک معمارانه

3. تعریف مساله1 • امنیت مدیریت ریسک است. • 50 درصد مشکلات امنیتی ناشی از عیوب طراحی • اتکاء به کد برای پیدا کردن این عیوب کارساز نیست! • نیاز به درک سطح بالاتری از کد • باور غلط برخی توسعه‌دهندگان :‌ توصیف سطح کدی برای یافتن مشکلات طراحی هم کافی است.<<<برنامه‌نویسی eXtreme: کد همان طراحی است<<<< نگاهی به نتایج مسابقات برنامه‌های مبهم‌سازی شده بیندازیـــد!!!

4. تعریف مساله2 • صراحتا ریسک شناسایی شده و اثرات به طور کمی تبیین می شوند. • انجام تحلیل ریسک به صورت اقتضایی (ad hoc) <<< مقیاس‌پذیر و قابل تکرار نیست<<< نتایج به شدت به افراد وابسته اند • در حال حاضر هرکس برای خودش رویه ای دارد <<< نتایج قابل مقایسه نیست

5. رویکرد سنتی تحلیل ریسک • متدولوژی های سنتی متنوعند و ریسک را از جنبه های مختلفی می نگرند. • مثال‌هایی از رویکردهای پایه : • متدولوژی‌های ضرر مالی: سعی در ترسیم وضعیت میزان ضرر مالی احتمالی در برابر هزینه پیاده‌سازی کنترل های مختلف • روش‌های رتبه‌بندی ریسک: فرموله کردن ریسک‌ بر مبنای تهدید، احتمال وقوع و اثرش کردن. • تکنیک‌های ارزیابی کیفی: ارزیابی ریسک با فاکتور‌های دانش بنیان و یافتاری • مثال از یک روش سنتی • ALE = SLE x ARO • where SLE is the Single Loss Expectancy & • ARO is the Annualized Rate of Occurrence

6. صرف نظر از نام تکنیک، ایده اغلب این روش‌ها<<<بررسی ROIبرای تعیین مقرون به صرفه بودن یک راه‌حل • مناسب بودن ROI در تجارت <<<<چقدر در امنیت مفهوم دارد ؟ • یک مفهوم ممکن : لزوم ملاحظه امنیت در آغاز چرخه برای هزینه کرد کمتر<<< ظهور مفهوم ROSI(return on security investment )<<< کافی به نظر نمی رسد • شباهت بیشتر امنیت با بیــمه تا با سرمایه ! • وقتی امنیت برقرار است چیزی به دست نمی‌‌آورید. وقتی برقرار نیست از دست می‌دهید!!

7. رویکرد‌های مدرن تر • دشواری اعمال مستقیم خروجی روش‌های سنتی به معماری نرم‌افزارهای مدرن • وجود امنیت در همه لایه‌های مدل OSI در چارچوب‌های مدرنی همچون .NETوJ2EEدر برنامه‌های کاربردی اما .... • اغلب حفاظت منفعلانه (دیوار آتش و SSL) <<< تنها حفاظت لایه 4 به پایین • یک راه حل ممکن :اتخاذ رویکرد تحلیل ریسک در سطح جزء به جزء، لایه‌ به لایه و محیط به محیط برای اندازه گیری تهدیدات، ریسک‌‌ها، آسیب‌پذیری‌ها و اثرات در این سطوح • راه حل دیگر ملاحظه ریسک در تمام چرخه (حتی در مرحله نیازمندی‌ها)

8. ملاحظه ریسک در مرحله نیازمندی‌ها<<< شکستن نیازمندی‌ها به سه دسته ساده حتما باید باشد مهم است که داشته باشد خوب ولی غیر ضروری است که داشته باشد قوانین و مقررات در دسته اول مثال الزام قانونی برای حفاظت از اطلاعات شخصی <<< اجبار در کار است و موضوع تصمیم‌گیری ریسک‌‌‌‌-مبنا نخواهد بود چرا؟ قدرت کافی دولت برای زیر سوال بردن همه تجارت شما، مادر همه ریسک‌ها! در نظر گرفتن حتی همین ایده‌های ساده شما را در زمره پیشتازان اکثر توسعه دهندگان قرار می‌دهد! در نهایت تست و برنامه‌ریزی تست باید بر اساس نتیجه تحلیل ریسک صورت گیرد. SecureUMLمتودولوژی مدل کردن سیاست‌های کنترل دسترسی و تجمیع آنها در یک فرآیند توسعه نرم‌افزار مدل بنیان UMLsecتوسعه ای بر UML برای در بر گیری مدل سازی ویژگی‌های امنیتی مثل محرمانگی و کنترل دسترسی .....

9. در نظر گرفتن حتی همین ایده‌های ساده شما را در زمره پیشتازان اکثر توسعه دهندگان قرار می‌دهد! • در نهایت تست و برنامه‌ریزی تست باید بر اساس نتیجه تحلیل ریسک صورت گیرد. • SecureUMLمتدولوژی مدل کردن سیاست‌های کنترل دسترسی و تجمیع آنها در یک فرآیند توسعه نرم‌افزار مدل بنیان • UMLsecتوسعه ای بر UML برای در بر گیری مدل سازی ویژگی‌های امنیتی مثل محرمانگی و کنترل دسترسی • ..... توسعه امن نرم‌افزار دکتر رسول جلیلی

10. UMLSEC UmlSec تعریف مدل حمله کننده

11. UMLSEC تعریف 21 نوع قالب درUMLSec

12. آنچه باید انجام‌گیرد... آموختن هرچه بیشتر درباره سیستم هدف خواندن و فهم مشخصات ، مستندات معماری و دیگر موجودیت‌های مربوط به طراحی بحث گروهی و پای‌تخته ای درباره سیستم هدف تعریف مرزهای سیستم و تعیین میزان حساسیت/بحرانی بودن داده ها کار با نرم‌افزار (در صورت قابل اجرا بودن) مطالعه کد و دیگر مصنوعات نرم‌افزاری(با کمک ابزارهای تحلیل کد ) شناسایی تهدیدات و توافق بر سر تهدیدات مربوط و ریشه های حملات (مثلا آیا کاربران داخلی به عنوان تهدید در نظر گرفته می شوند؟) مباحثه درباب مسائل امنیتی مربوط به نرم افزار بحث درباره اینکه نرم‌افزار چگونه کار می‌کند <<<تعیین نقاط ابهام و اختلاف شناسایی آسیب پذیری‌های ممکن (با کمک ابزار یا لیست آسیب‌پذیری‌های متداول ) درک کنترل های امنیتی موجود <<< خود این کنترل ها می توانند مسبب ریسک‌های امنیتیدیگری باشند هرچند برخی دیگر مشکلات را مرتفع کنند

13. آنچه باید انجام‌گیرد... تعیین احتمال سو استفاده تهیه سناریوهای حمله دربرابر هم قرار دادن کنترل های امنیتی در قبال ظرفیت تهدیدات برای تعیین احتمال وقوع انجام تحلیل اثر تعیین اثرات روی سرمایه و اهداف تجاری ملاحظه اثرات روی وضعیت امنیتی رتبه بندی ریسک توسعه راهبرد کاهش ریسک گزارش یافته‌ها توصیف دقیق ریسک‌های مهم و نیز کم اهمیت با توجه به اثراتشان تهیه اطلاعاتی درباب انینکه منابع محدود موجود برای کاهش ریسک در کجا باید هزینه شوند؟

14. رویکـــــرد پیشـــنهادیـــــ در قالب مراحل چرخه 1 2 3

15. تحلیل ریسک معمارانه<<<پیشنهاد یک رویکرد سه گامی:: • تحلیل مقاومت در برابر حملات • تحلیــــــل ابهــــــام‌ها • تحلیل ضـــــــعــــف‌ها • نقش دانش در هر سه این مراحل • استفاده از الگوهای حملات و گراف های اکسپلویت برای فهم مقاومت در برابر حملات • دانش اصول طراحی برای استفاده در تحلیل ابهام‌ • دانش مسائل امنیتی در چارچوب‌های متداول روز مثل .NETوJ2EE برای انجام تحلیل ضعف‌ها

16. 1- تحلیل مقاومت در برابر حملات ایده استفاده از اطلاعات درباره حملات شناخته شده، الگوی حملات، آسیب پذیری‌ها در طول تحلیل رویکردی چک‌لیستی شناسایی عیوب عمومی با استفاده از چک لیست‌ها و منابع موجود برای طراحی امن استخراج الگوی حملات با استفاده از نتیجه سوءکاربردها و لیستی از الگوی حملات فهم و نمایش انجام‌پذیری این حملات با کمک چیزهایی شبیه گراف‌های اکسپلویت این مرحله به یافتن مشکلات شناخته شده کمک می کند اما ... برای یافتن حملات جدید و یا دیگر ابتکارات کافی نیست.

17. 2- تحلیل ابهام‌ها فعالیت‌های مبتکرانه‌ای که برای کشف ریسک‌های تازه صورت می‌گیرد نیاز به حداقل دو تحلیل‌گر و مقداری تجربه! انجام تحلیل موازی توسط هریک از افراد <<<< بعد از اتمام تحلیل جداگانه ،مرحله یکسانسازی درک‌ها-جلسه با تخته سیاه! جایی که معماران خوب بر سر آن توافق ندارند <<<< چیزهایی جالبی در اینجا هست (گاهی عیوب طراحی) و ریسک‌ها تحلیل ابهام‌ها به یافتن ابهام و ناسازگاری کمک می‌کند.

18. 3-تحلیل ضعف‌ها هدف:‌ فهم اثر وابستگی‌های خارجی نرم‌افزار نرم‌افزار دیگر یکپارچه توسعه داده نمی‌شود. ضعف در این اجزا : بسته‌های خارجی برای تامین ویژگی‌های امنیتی چارچوب‌های مختلف توپولوژی‌های مختلف شبکه سکوهای نرم‌افزاری محیط فیزیکی ( وسایل ذخیره‌سازی مثل USB و یا iPodها) محیط ساخت (کامپایلر مسموم، ماشین سازنده آلوده به روت‌کیت و ...) تجربه بالای کار با کتابخانه‌ها، سیستم‌های مختلف و سکوها برای این تیم با ارزش است. متاسفانه نرم‌افزار خاصی به این منظور وجود ندارد مثال‌هایی از مسائلی که دراین تحلیل می تواند روشن شود : عدم موفقیت مرورگر یا هر جعبه شنی مجازی پشتیبانی سرویس نا امن RMI و COM واسط های دیباگ همان اندازه مفید برای حمله کننده که برای توسعه دهنده! خطاها را برای (سوء)کاربرانتان نفرستید! ویژگی‌های استفاده نشده (ولی ممتاز) حملات میانی جعل کارخواه و مرد میانی، مسیرهای جعلی به کتابخانه ها و ... )

19. جمع‌بندیــ این تحلیل کلی کمی دشوار به نظر میرسد <<< در عمل نباید چندان سخت باشد. با چیزی شبیه مدلSTRIDEشروع کنید شما هم از چک لیست‌های الگوی حملات استفاده کنید<<<< حمله کننده‌ها نیز همین کار را می‌کنند.

20. ایده‌های مقایسه معمارانه 1 خارج از مباحث کتاب چرخه مک‌گرا تهدیدمبنا و بر اساس سناریو‌های سوء کاربرد(1) ایده اصلی :‌ معماری‌های مختلفی می‌توانند نیازمندی‌ها را ارضا کنند<<< نیاز به انتخاب امن‌ترین معماری یک رویکرد 4 مرحله‌ای تحلیل نیازمندی به صورت تهدید مبنا تجزیه کاربرد ارائه معماری‌های کاندیدا و ارزیابی آن‌ها بر اساس سناریوهای کاربرد و سوء کاربرد انتخاب یک معماری امن نهایی (1)Xu, Dianxiang, and Josh Pauli. "Threat-driven design and analysis of secure software architectures." Journal of Information Assurance and Security 1.3 (2006): 171-180. (2)Gennari, Jeffrey, and David Garlan. Measuring Attack Surface in Software Architecture. Technical Report CMU-ISR-11-121, Carnegie Mellon University, 2012.

21. ایده‌های مقایسه معمارانه 2 خارج از مباحث کتاب چرخه مک‌گرا 2- بر اساس اندازه‌گیری کمی سطح حملات در طراحی انجام شده (2) معرفی سه تایی نشان دهنده سطح حمله در زمان طراحی بر اساس معیار Damage-Effort Ratio (DER) میزان جذابیت هر منبع برای حمله کننده و پتانسیل حمله بدان : DER mمیزان حقوقی که برای دسترسی به منبع لازم است(privileges/access rights) DER c میزان محدودیتی که پروتکل بر روی داده های منتقل شده روی کانال اعمال می کند. DER I پتانسیل حمله ای که به دلیل وجود داده‌های غیر معتمد در سیستم به وجود می‌آید. -محاسبه این معیارها برای نقاط ورودی و خروجی در دیاگرام جریان برنامه طراحی شده (2)Gennari, Jeffrey, and David Garlan. Measuring Attack Surface in Software Architecture. Technical Report CMU-ISR-11-121, Carnegie Mellon University, 2012.

22. جلسه آینـــده از جالب‌ترین مباحث! تست نفـــــــــوذ