UMLsec

Report
‫بسم هللا الرحمن الرحیم‬
‫فصل چهارم‬
2
‫‪‬‬
‫امنیت مدیریت ریسک است‪.‬‬
‫‪ 50 ‬درصد مشکالت امنیتی ناشی از عیوب طراحی‬
‫‪‬‬
‫اتکاء به کد برای پیدا کردن این عیوب کارساز نیست!‬
‫‪ ‬نیاز به درک سطح باالتری از کد‬
‫‪‬‬
‫باور غلط برخی توسعه‌دهندگان ‪ :‬توصیف سطح کدی برای یافتن مشکالت طراحی‬
‫هم کافی است‪<<<.‬برنامه‌نویسی‬
‫‪ :eXtreme‬کد همان طراحی است <<<<‬
‫نگاهی به نتایج مسابقات برنامه‌های مبهمسازی شده بیندازیـــد!!!‬
‫‪3‬‬
‫‪‬‬
‫صراحتا ریسک شناسایی شده و اثرات به طور کمی تبیین می شوند‪.‬‬
‫‪‬‬
‫انجام تحلیل ریسک به صورت اقتضایی (‪ <<< )ad hoc‬مقیاس‌پذیر و‬
‫قابل تکرار نیست<<< نتایج به شدت به افراد وابسته اند‬
‫‪‬‬
‫در حال حاضر هرکس برای خودش رویه ای دارد <<< نتایج قابل مقایسه‬
‫نیست‬
‫‪4‬‬
‫‪5‬‬
‫‪ ‬متدولوژی های سنتی متنوعند و ریسک را از جنبه های مختلفی می نگرند‪.‬‬
‫‪ ‬مثالهایی از رویکردهای پایه ‪:‬‬
‫‪ ‬متدولوژیهای ضرر مالی‪ :‬سعی در ترسیم وضعیت میزان ضرر مالی احتمالی‬
‫در برابر هزینه پیادهسازی کنترل های مختلف‬
‫‪ ‬روشهای رتبهبندی ریسک‪ :‬فرموله کردن ریسک بر مبنای تهدید‪ ،‬احتمال‬
‫وقوع و اثرش کردن‪.‬‬
‫‪ ‬تکنیکهای ارزیابی کیفی‪:‬‬
‫ارزیابی ریسک با فاکتورهای دانش بنیان و‬
‫یافتاری‬
‫‪ ‬مثال از یک روش سنتی‬
‫‪ ALE = SLE x ARO‬‬
‫& ‪where SLE is the Single Loss Expectancy‬‬
‫‪ARO is the Annualized Rate of Occurrence‬‬
‫‪ ‬صرف نظر از نام تکنیک‪ ،‬ایده اغلب این روش‌ها<<< بررسی ‪ ROI‬برای‬
‫تعیین مقرون به صرفه بودن یک راه‌حل‬
‫‪ ‬مناسب بودن ‪ ROI‬در تجارت <<<< چقدر در امنیت مفهوم دارد‬
‫؟‬
‫‪ ‬یک مفهوم ممکن ‪ :‬لزوم مالحظه امنیت در آغاز چرخه برای هزینه‬
‫کرد کمتر<<< ظهور مفهوم ‪return on security (ROSI‬‬
‫‪ <<<)investment‬کافی به نظر نمی رسد‬
‫‪‬شباهت بیشتر امنیت با بیــمه‬
‫تا با سرمایه‬
‫!‬
‫‪ ‬وقتی امنیت برقرار است چیزی به دست نمی‌‌آورید‪ .‬وقتی برقرار نیست از‬
‫‪6‬‬
‫‪7‬‬
‫‪ ‬دشواری اعمال مستقیم خروجی روش‌های سنتی به معماری نرم‌افزارهای مدرن‬
‫‪ ‬وجود امنیت در همه الیه‌های مدل ‪ OSI‬در چارچوب‌های مدرنی همچون‬
‫‪.NET‬و‪ J2EE‬در برنامه‌های کاربردی اما ‪....‬‬
‫‪ ‬اغلب حفاظت منفعالنه (دیوار آتش و ‪ <<< )SSL‬تنها حفاظت الیه ‪ 4‬به پایین‬
‫‪ ‬یک راه حل ممکن ‪:‬اتخاذ رویکرد تحلیل ریسک در سطح جزء به جزء‪ ،‬الیه به‬
‫الیه و محیط به محیط برای اندازه گیری تهدیدات‪ ،‬ریسک‌‌ها‪ ،‬آسیب‌پذیری‌ها و‬
‫اثرات در این سطوح‬
‫‪ ‬راه حل دیگر مالحظه ریسک در تمام چرخه (حتی در مرحله نیازمندیها)‬
‫‪‬‬
‫مالحظه‌ریسک‌در‌مرحله‌نیازمندی‌ها <<<شکستن‌نیازمندی‌ها‌به‌سه‌دسته‌ساده‌‬
‫‪‬‬
‫حتما‌باید‌باشد‬
‫‪‬‬
‫مهم‌است‌که‌داشته‌باشد‌‬
‫‪‬‬
‫خوب‌ولی‌غیر‌ضروری‌است‌که‌داشته‌باشد‌‬
‫‪‬‬
‫قوانین‌و‌مقررات‌در‌دسته‌اول‌‬
‫‪‬‬
‫مثال‌الزام‌قانونی‌برای‌حفاظت‌از‌اطالعات‌شخصی‌<<< اجبار‌در‌کار‌است‌و‌موضوع‌تصمیم‌گیری‌‌‬
‫ریسک‪-‬مبنا‌نخواهد‌بود‌‬
‫‪‬‬
‫چرا؟‌قدرت‌کافی‌دولت‌برای‌زیر‌سوال‌بردن‌همه‌تجارت‌شما‪‌،‬مادر‌همه‌ریسک‌ها!‬
‫‪‬‬
‫در نظر گرفتن حتی همین ایدههای ساده شما را در زمره پیشتازان اکثر توسعه دهندگان قرار میدهد!‬
‫‪‬‬
‫در‌نهایت‌تست‌و‌برنامه‌ریزی‌تست‌باید‌بر‌اساس‌نتیجه‌تحلیل‌ریسک‌صورت‌گیرد‪.‬‬
‫‪‬‬
‫‪ SecureUML‬متودولوژی‌مدل‌کردن‌سیاست‌های‌کنترل‌دسترسی‌و‌تجمیع‌آنها‌در‌یک‌فرآیند‌توسعه‌‬
‫نرم‌افزار‌مدل‌بنیان‬
‫‪‬‬
‫‪ UMLsec‬توسعه‌ای‌بر‌‪ UML‬برای‌در‌بر‌گیری‌مدل‌سازی‌ویژگی‌های‌امنیتی‌مثل‌محرمانگی‌و‌کنترل‌‬
‫دسترسی‬
‫‪‬‬
‫‪8‬‬
‫‪.....‬‬
‫‪ ‬در نظر گرفتن حتی همین ایدههای ساده شما را در زمره‬
‫پیشتازان اکثر توسعه دهندگان قرار میدهد!‬
‫‪ ‬در‌نهایت‌تست‌و‌برنامه‌ریزی‌تست‌باید‌بر‌اساس‌نتیجه‌‬
‫تحلیل‌ریسک‌صورت‌گیرد‪.‬‬
‫‪‬‬
‫‪ SecureUML‬متدولوژی‌مدل‌کردن‌سیاست‌های‌کنترل‌‬
‫دسترسی‌و‌تجمیع‌آنها‌در‌یک‌فرآیند‌توسعه‌نرم‌افزار‌مدل‌‬
‫بنیان‬
‫‪ UMLsec ‬توسعه‌ای‌بر‌‪ UML‬برای‌در‌بر‌گیری‌مدل‌‬
‫سازی‌ویژگی‌های‌امنیتی‌مثل‌محرمانگی‌و‌کنترل‌دسترسی‬
‫‪..... ‬‬
‫‪9‬‬
‫توسعه‌امن‌نرم‌افزار‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌دکتر‌رسول‌جلیلی‬
‫‪UmlSec‬‬
‫تعریف مدل حمله کننده‬
‫‪10‬‬
‫تعریف ‪ 21‬نوع قالب در ‪UMLSec‬‬
‫‪11‬‬
‫‪‬خواندن‌و‌فهم‌مشخصات‌‪‌،‬مستندات‌معماری‌و‌دیگر‌موجودیت‌های‌مربوط‌به‌طراحی‌‬
‫‪‬بحث‌گروهی‌و‌پای‌تخته‌ای‌درباره‌سیستم‌هدف‌‬
‫‪‬تعریف‌مرزهای‌سیستم‌و‌تعیین‌میزان‌حساسیت‪/‬بحرانی‌بودن‌داده‌ها‬
‫‪‬کار‌با‌‌نرم‌افزار‌(در‌صورت‌قابل‌اجرا‌بودن)‬
‫‪‬مطالعه‌کد‌و‌دیگر‌مصنوعات‌نرم‌افزاری(با‌کمک‌ابزارهای‌تحلیل‌کد‌)‬
‫‪‬شناسایی‌تهدیدات‌و‌توافق‌بر‌سر‌تهدیدات‌مربوط‌و‌ریشه‌های‌حمالت‌(مثال‌آیا‌کاربران‌داخلی‌به‌عنوان تهدید‌در‌‬
‫نظر‌گرفته‌می‌شوند؟)‬
‫‪‬بحث‌درباره‌اینکه‌نرم‌افزار‌چگونه‌کار‌می‌کند‌<<<تعیین‌نقاط‌ابهام‌و‌اختالف‌‬
‫‪‬شناسایی‌آسیب‌پذیری‌های‌ممکن‌(با‌کمک‌ابزار‌یا‌لیست‌آسیب‌پذیری‌های‌متداول‌)‬
‫‪‬درک‌کنترل‌های‌امنیتی‌موجود‌<<< خود‌این‌کنترل‌ها‌می‌توانند‌‌مسبب‌ریسک‌های‌امنیتی دیگری‌باشند‌‌‬
‫‪12‬‬
‫هرچند‌برخی‌دیگر‌مشکالت‌را‌مرتفع‌کنند‬
‫‪‬تهیه‌سناریوهای‌حمله‌‬
‫‪‬دربرابر‌هم‌قرار‌دادن‌کنترل‌های‌امنیتی‌در‌قبال‌ظرفیت‌تهدیدات‌برای‌تعیین احتمال‌‬
‫وقوع‌‬
‫‪ ‬تعیین‌اثرات‌روی‌سرمایه‌و‌اهداف‌تجاری‌‬
‫‪ ‬مالحظه‌اثرات‌روی‌وضعیت‌امنیتی‌‬
‫‪13‬‬
‫‪ ‬توصیف‌دقیق‌ریسک‌های‌مهم‌و‌نیز‌کم‌اهمیت‌با‌توجه‌به‌اثراتشان‌‬
‫‪ ‬تهیه‌اطالعاتی‌درباب‌انینکه‌منابع‌محدود‌موجود‌برای‌کاهش‌ریسک‌در‌کجا‌باید‌‬
‫هزینه‌شوند؟‬
‫‪14‬‬
‫در قالب مراحل چرخه‬
‫‪1‬‬
‫‪2‬‬
‫‪3‬‬
‫‪ ‬تحلیل ریسک معمارانه<<<پیشنهاد یک رویکرد سه گامی‪::‬‬
‫‪ ‬تحلیل مقاومت در برابر حمالت‬
‫‪ ‬تحلیــــــل ابهــــــامها‬
‫‪ ‬تحلیل ضـــــــعــــفها‬
‫‪ ‬نقش دانش در هر سه این مراحل‬
‫‪ ‬استفاده از الگوهای حمالت و گراف های اکسپلویت برای‬
‫فهم مقاومت در برابر حمالت‬
‫‪ ‬دانش اصول طراحی برای استفاده در تحلیل ابهام‬
‫‪ ‬دانش مسائل امنیتی در چارچوبهای متداول روز مثل‬
‫‪.NET‬و‪J2EE‬‬
‫‪15‬‬
‫برای انجام تحلیل ضعفها‬
‫‪16‬‬
‫‪‬‬
‫ایده استفاده از اطالعات درباره حمالت شناخته شده‪ ،‬الگوی حمالت‪ ،‬آسیب پذیریها در طول تحلیل‬
‫‪‬‬
‫رویکردی چکلیستی‬
‫‪‬‬
‫شناسایی عیوب عمومی با استفاده از چک لیستها و منابع موجود برای طراحی امن‬
‫‪‬‬
‫استخراج الگوی حمالت با استفاده از نتیجه سوءکاربردها و لیستی از الگوی حمالت‬
‫‪‬‬
‫فهم و نمایش انجامپذیری این حمالت با کمک چیزهایی شبیه گرافهای اکسپلویت‬
‫‪‬‬
‫این مرحله به یافتن مشکالت شناخته شده کمک می کند اما ‪...‬‬
‫‪‬‬
‫برای یافتن حمالت جدید و یا دیگر ابتکارات کافی نیست‪.‬‬
‫‪17‬‬
‫‪‬‬
‫فعالیتهای مبتکرانهای که برای کشف ریسکهای تازه صورت میگیرد‬
‫‪‬‬
‫نیاز به حداقل دو تحلیلگر و مقداری تجربه!‬
‫‪‬‬
‫انجام تحلیل موازی توسط هریک از افراد <<<< بعد از اتمام تحلیل جداگانه ‪،‬مرحله‬
‫یکسانسازی درکها‪-‬جلسه با تخته سیاه!‬
‫‪ ‬جایی که معماران خوب بر سر آن توافق ندارند <<<< چیزهایی جالبی در اینجا هست (گاهی‬
‫عیوب طراحی) و ریسکها‬
‫‪‬‬
‫تحلیل ابهامها به یافتن ابهام و ناسازگاری کمک میکند‪.‬‬
‫‪18‬‬
‫‪ ‬هدف‪‌‌:‬فهم اثر وابستگیهای خارجی نرمافزار‬
‫‪ ‬نرم‌افزار‌دیگر‌یکپارچه‌توسعه‌داده‌نمی‌شود‪.‬‬
‫‪ ‬ضعف‌در‌این‌اجزا‌‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫بسته‌های‌خارجی‌برای‌تامین‌ویژگی‌های‌امنیتی‬
‫چارچوب‌های‌مختلف‌‬
‫توپولوژی‌های‌مختلف‌شبکه‌‬
‫سکوهای‌نرم‌افزاری‬
‫محیط‌فیزیکی‌( وسایل‌ذخیره‌سازی‌مثل‌‪ USB‬و‌یا‌‪iPod‬ها)‬
‫محیط‌ساخت‌(کامپایلر‌مسموم‪‌،‬ماشین‌سازنده‌آلوده‌به‌روت‌کیت‌و‌‪)...‬‬
‫‪ ‬تجربه‌باالی‌کار‌با‌کتابخانه‌ها‪‌،‬سیستم‌های‌مختلف‌و‌سکوها‌برای‌این‌تیم‌با‌ارزش‌است‪.‬‬
‫‪ ‬متاسفانه‌نرم‌افزار‌خاصی‌به‌این‌منظور‌وجود‌ندارد‌‬
‫‪ ‬مثال‌هایی‌از‌مسائلی‌که‌دراین‌تحلیل‌می‌تواند‌روشن‌شود‌‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫عدم‌موفقیت‌مرورگر‌یا‌هر‌جعبه‌شنی‌مجازی‌‬
‫پشتیبانی‌سرویس‌نا‌امن‌‪ RMI‬و‌‪COM‬‬
‫واسط‌های‌دیباگ‌همان‌اندازه‌مفید‌برای‌حمله‌کننده‌که‌برای‌توسعه‌دهنده! خطاها‌را‌برای‌(سوء)کاربرانتان‌‬
‫نفرستید!‬
‫ویژگی‌های‌استفاده‌نشده‌(ولی‌ممتاز)‬
‫حمالت‌میانی‌جعل‌کارخواه‌و‌مرد‌میانی‪‌،‬مسیرهای‌جعلی‌به‌کتابخانه‌ها‌و‌‪) ...‬‬
‫‪19‬‬
‫‪‬‬
‫این تحلیل کلی کمی دشوار به نظر میرسد‬
‫<<< در عمل نباید چندان سخت باشد‪.‬‬
‫‪‬‬
‫با چیزی شبیه مدل ‪ STRIDE‬شروع کنید‬
‫‪‬‬
‫شما هم از چک لیستهای الگوی حمالت‬
‫استفاده کنید <<<< حمله کنندهها نیز همین‬
‫کار را میکنند‪.‬‬
‫‪20‬‬
‫خارج از مباحث کتاب چرخه مکگرا‬
‫تهدیدمبنا و بر اساس سناریوهای سوء کاربرد(‪)1‬‬
‫‪ ‬ایده‌اصلی‌‪ :‬معماری‌های‌مختلفی‌می‌توانند‌نیازمندی‌ها‌را‌ارضا‌کنند<<< نیاز‌به‌انتخاب‌‬
‫امن‌ترین‌معماری‌‬
‫‪ ‬یک‌رویکرد‌‪ 4‬مرحله‌ای‬
‫‪.1‬‬
‫‪.2‬‬
‫‪.3‬‬
‫‪.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‬‬
‫معرفی سه تایی نشان دهنده سطح حمله در زمان طراحی بر اساس معیار ‪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‬‬
‫•‬
‫از جالبترین مباحث!‬
‫•‬
‫تست نفـــــــــوذ‬

similar documents