YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: توسعه  امن نرمافزار

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

رسول‌جلیلی

91زمستان‌

بسم الله الرحمن الرحیم

فصل چهارم

Page 2: توسعه  امن نرمافزار

2

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

Page 3: توسعه  امن نرمافزار

3

‌1تعریف‌مساله.امنیت‌مدیریت‌ریسک‌است

50درصد‌مشکالت‌امنیتی‌ناشی‌از‌عیوب‌طراحی‌

‌!اتکاء‌به‌کد‌برای‌پیدا‌کردن‌این‌عیوب‌کارساز‌نیست

نیاز‌به‌درک‌سطح‌باالتری‌از‌کد‌

باور‌غل@ط‌ب@رخی‌توس@عه‌دهندگان‌:‌‌توص@یف‌س@طح‌ک@دی‌ب@رای‌ی@افتن‌

‌:‌eXtreme>>>برنامه‌نویس@ی‌مش@کالت‌ط@راحی‌هم‌ک@افی‌اس@ت.

مس@ابقات‌ نت@ایج‌ ب@ه‌ نگ@اهی‌ ‌ اس@ت>>>>‌ ط@راحی‌ هم@ان‌ ک@د‌

‌شده‌بیندازی@@@د!!!مبهم سازیبرنامه‌های‌

Page 4: توسعه  امن نرمافزار

4

2تعریف‌مساله

صراحتا‌ریس@ک‌شناس@ایی‌ش@ده‌و‌اث@رات‌ب@ه‌ط@ور‌کمی‌تب@یین‌می‌

شوند.

( اقتض@ایی‌ ‌ ب@ه‌ص@ورت‌ ریس@ک‌ تحلی@ل‌ (‌>>>‌ad‌hocانج@ام‌

مقیاس‌پ@ذیر‌‌و‌قاب@ل‌تک@رار‌نیس@ت>>>‌نت@ایج‌ب@ه‌ش@دت‌ب@ه‌اف@راد‌

وابسته‌اند

در‌ح@ال‌حاض@ر‌ه@رکس‌ب@رای‌خ@ودش‌روی@ه‌ای‌دارد‌>>>‌نت@ایج‌

قابل‌مقایسه‌نیست

Page 5: توسعه  امن نرمافزار

5رویکرد سنتی تحلیل ریسک

مت%دولوژی ه%ای س%نتی متنوعن%د و ریس%ک را از جنب%ه ه%ای

مختلفی می نگرند.

: مثال هایی از رویکردهای پایه

س%عی در ترس%یم وض%عیت مت%دولوژی های ض%رر م%الی :

م%یزان ض%رر م%الی احتم%الی در براب%ر هزین%ه پیاده س%ازی

کنترل های مختلف

روش ه%ای رتبه بن%دی ریس%ک: فرمول%ه ک%ردن ریس%ک ب%ر

مبنای تهدید، احتمال وقوع و اثرش کردن.

ب%%ا ریس%%ک ارزی%%ابی کیفی: ارزی%%ابی تکنیک ه%%ای

فاکتور های دانش بنیان و یافتاری

مثال‌از‌یک‌روش‌سنتی‌‌

ALE‌=‌SLE‌x‌ARO

‌where‌SLE‌is‌the‌Single‌Loss‌Expectancy‌&‌

‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌ARO‌is‌the‌Annualized‌Rate‌of‌

Occurrence

Page 6: توسعه  امن نرمافزار

6

روش‌ه@ا این‌ اغلب‌ ای@ده‌ تکنی@ک،‌ ن@ام‌ از‌ نظ@ر‌ >>>‌صرف‌

ب@رای‌تع@یین‌مق@رون‌ب@ه‌ص@رفه‌ب@ودن‌ی@ک‌راه‌ح@ل‌ ROIبررس%ی

مناس@ب‌ب@ودن‌ROI‌<<<<چق@در‌در‌ام@نیت‌‌در‌تج@ارت‌

مفهوم‌دارد‌؟‌:ل%زوم مالحظ%ه ام%نیت در آغ%از یک‌مفه@وم‌ممکن‌

ظه%ور کم%تر>>> ک%رد هزین%ه ب%رای چرخ%ه

ROSI(return on securityمفه%%%وم

investment )<<<کافی‌به‌نظر‌نمی‌رسد‌

سرمایه تا‌با‌ بی%%مه شباهت‌بیشتر‌امنیت‌با‌!

وق@تی‌ام@نیت‌برق@رار‌اس@ت‌چ@یزی‌ب@ه‌دس@ت‌نمی‌‌آوری@د.‌وق@تی‌

برقرار‌نیست‌از‌دست‌می‌دهید!!

Page 7: توسعه  امن نرمافزار

رویکرد های مدرن تر7

دش@واری‌اعم@ال‌مس@تقیم‌خ@روجی‌روش‌ه@ای‌س@نتی‌ب@ه‌معم@اری‌

نرم‌افزارهای‌مدرن

وج@ود‌ام@نیت‌در‌هم@ه‌الیه‌ه@ای‌م@دل‌OSIدر‌چارچوب‌ه@ای‌م@درنی‌‌

‌‌در‌برنامه‌های‌کاربردی‌اما‌....J2EEوNETهمچون‌.

دی@وار‌آتش‌و‌(اغلب‌حف@اظت‌منفعالن@ه‌SSLتنه@ا‌حف@اظت‌‌<<<‌)

‌به‌پایین‌4الیه‌

یک‌راه‌ح@ل‌ممکن‌:اتخ@اذ‌رویک@رد‌تحلی@ل‌ریس@ک‌در‌س@طح‌ج@زء‌ب@ه‌

گ@یری‌ ان@دازه‌ ب@رای‌ محی@ط‌ ب@ه‌ محی@ط‌ و‌ ‌ الی@ه‌ ب@ه‌ الیه‌‌ ج@زء،‌

تهدیدات،‌ریسک‌‌ها،‌آسیب‌پذیری‌ها‌و‌اثرات‌در‌این‌سطوح‌

راه ح%ل دیگ%ر مالحظ%ه ریس%ک در تم%ام چرخ%ه (ح%تی در

مرحله نیازمندی ها)

Page 8: توسعه  امن نرمافزار

8

شکستن‌نیازمندی‌ها‌به‌سه‌دسته‌ساده‌مالحظه‌ریسک‌در‌مرحله‌نیازمندی‌ها‌<<<

حتما‌باید‌باشد

مهم‌است‌که‌داشته‌باشد‌

خوب‌ولی‌غیر‌ضروری‌است‌که‌داشته‌باشد‌

قوانین‌و‌مقررات‌در‌دسته‌اول‌

مثال‌الزام‌قانونی‌برای‌حفاظت‌از‌اطالعات‌شخصی‌>>>‌اجبار‌در‌کار‌است‌و‌موضوع‌

تصمیم‌گیری‌‌ریسک‌‌‌‌-مبنا‌نخواهد‌بود‌

!چرا؟‌قدرت‌کافی‌دولت‌برای‌زیر‌سوال‌بردن‌همه‌تجارت‌شما،‌مادر‌همه‌ریسک‌ها

در نظر گرفتن حتی همین ایده های ساده شما را در زمره پیشتازان اکثر

توسعه دهندگان قرار می دهد!

.در‌نهایت‌تست‌و‌برنامه‌ریزی‌تست‌باید‌بر‌اساس‌نتیجه‌تحلیل‌ریسک‌صورت‌گیرد

SecureUMLمتودولوژی‌مدل‌کردن‌سیاست‌های‌کنترل‌دسترسی‌و‌تجمیع‌آنها‌در‌یک‌‌‌

فرآیند‌توسعه‌نرم‌افزار‌مدل‌بنیان

UMLsec توسعه‌ای‌بر‌UMLبرای‌در‌بر‌گیری‌مدل‌سازی‌ویژگی‌های‌امنیتی‌مثل‌‌

محرمانگی‌و‌کنترل‌دسترسی

.....

Page 9: توسعه  امن نرمافزار

توسعه‌امن‌نرم‌افزار‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌دکتر‌رسول‌جلیلی 9

در نظر گرفتن حتی همین ایده های ساده شما را

در زمره پیشتازان اکثر توسعه دهندگان قرار

می دهد!

در‌نهایت‌تست‌و‌برنامه‌ریزی‌تست‌باید‌بر‌اساس‌نتیجه‌

تحلیل‌ریسک‌صورت‌گیرد.

SecureUMLمتدولوژی‌مدل‌کردن‌سیاست‌های‌کنترل‌‌‌

دسترسی‌و‌تجمیع‌آنها‌در‌یک‌فرآیند‌توسعه‌نرم‌افزار‌مدل‌

بنیان

UMLsec توسعه‌ای‌بر‌UMLبرای‌در‌بر‌گیری‌مدل‌سازی‌‌

ویژگی‌های‌امنیتی‌مثل‌محرمانگی‌و‌کنترل‌دسترسی

.....

Page 10: توسعه  امن نرمافزار

10

UMLSEC

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

Page 11: توسعه  امن نرمافزار

11

UMLSEC

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

Page 12: توسعه  امن نرمافزار

12

آنچه‌باید‌انجام‌گیرد...آموختن هرچه بیشتر درباره سیستم هدف

خواندن‌و‌فهم‌مشخصات‌،‌مستندات‌معماری‌و‌دیگر‌موجودیت‌های‌مربوط‌به‌طراحی‌

بحث‌گروهی‌و‌پای‌تخته‌ای‌درباره‌سیستم‌هدف‌

تعریف‌مرزهای‌سیستم‌و‌تعیین‌میزان‌حساسیت/بحرانی‌بودن‌داده‌ها

)کار‌با‌‌نرم‌افزار‌)در‌صورت‌قابل‌اجرا‌بودن

)مطالعه‌کد‌و‌دیگر‌مصنوعات‌نرم‌افزاری)با‌کمک‌ابزارهای‌تحلیل‌کد‌

شناسایی‌تهدیدات‌و‌توافق‌بر‌سر‌تهدیدات‌مربوط‌و‌ریشه‌های‌حمالت‌)مثال‌آیا‌کاربران‌

داخلی‌به‌عنوان‌تهدید‌در‌نظر‌گرفته‌می‌شوند؟(

مباحثه درباب مسائل امنیتی مربوط به نرم افزار

بحث‌درباره‌اینکه‌نرم‌افزار‌چگونه‌کار‌می‌کند‌>>>تعیین‌نقاط‌ابهام‌و‌اختالف‌

)شناسایی‌آسیب‌پذیری‌های‌ممکن‌)با‌کمک‌ابزار‌یا‌لیست‌آسیب‌پذیری‌های‌متداول‌

درک‌کنترل‌های‌امنیتی‌موجود‌>>>‌خود‌این‌کنترل‌ها‌می‌توانند‌‌مسبب‌ریسک‌های‌

امنیتی‌دیگری‌باشند‌‌هرچند‌برخی‌دیگر‌مشکالت‌را‌مرتفع‌کنند

Page 13: توسعه  امن نرمافزار

13

آنچه‌باید‌انجام‌گیرد...تعیین احتمال سو استفاده

تهیه‌سناریوهای‌حمله‌

دربرابر‌هم‌قرار‌دادن‌کنترل‌های‌امنیتی‌در‌قبال‌ظرفیت‌تهدیدات‌

برای‌تعیین‌احتمال‌وقوع‌انجام‌تحلیل‌اثر•

تعیین‌اثرات‌روی‌سرمایه‌و‌اهداف‌تجاری‌مالحظه‌اثرات‌روی‌وضعیت‌امنیتی‌

رتبه بندی ریسک •توسعه راهبرد کاهش ریسک •گزارش یافته ها •

توصیف‌دقیق‌ریسک‌های‌مهم‌و‌نیز‌کم‌اهمیت‌با‌توجه‌به‌اثراتشان‌تهیه‌اطالعاتی‌درباب‌انینکه‌منابع‌محدود‌موجود‌برای‌کاهش‌

ریسک‌در‌کجا‌باید‌هزینه‌شوند؟

Page 14: توسعه  امن نرمافزار

14

رویک%%%%%رد پیش%%%نهادی%%%%%در قالب مراحل چرخه

1

2

3

Page 15: توسعه  امن نرمافزار

15

پیشنهاد یک تحلیل ریسک معمارانه<<<

رویکرد سه گامی::

تحلیل مقاومت در برابر

حمالت

تحلی%%%%%%ل ابه%%%%%%ام ها

تحلیل ض%%%%%%%ع%%%%ف هادر هر سه این مراحل دانش نقش

استفاده از الگوهای حمالت و گراف

های اکسپلویت برای فهم مقاومت در

برابر حمالت

دانش اصول طراحی برای استفاده در

تحلیل ابهام

دانش مسائل امنیتی در چارچوب های

برای J2EEوNETمتداول روز مثل .

انجام تحلیل ضعف ها

Page 16: توسعه  امن نرمافزار

16تحلیل مقاومت در برابر -1 حمالت

،ایده استفاده از اطالعات درباره حمالت شناخته شده، الگوی حمالت

آسیب پذیری ها در طول تحلیل

رویکردی چک لیستی

شناسایی عیوب عمومی با استفاده از چک لیست ها و منابع موجود برای

طراحی امن

و لیستی از الگوی نتیجه سوءکاربردها استخراج الگوی حمالت با استفاده از

حمالت

فهم و نمایش انجام پذیری این حمالت با کمک چیزهایی شبیه گراف های

اکسپلویت

اما ...کمک می کند مشکالت شناخته شده این مرحله به یافتنبرای یافتن حمالت جدید و یا دیگر ابتکارات کافی نیست.

Page 17: توسعه  امن نرمافزار

تحلیل ابهام ها -172

فعالیت ه%ای مبتک%رانه ای ک%ه ب%رای کش%ف ریس%ک های ت%ازه ص%ورت

می گیرد

!نیاز به حداقل دو تحلیل گر و مقداری تجربه

بع%د از اتم%ام انج%ام تحلی%ل م%وازی توس%ط هری%ک از اف%راد <<<<

تحلیل جداگانه ،مرحله یکسانسازی درک ها-جلسه با تخته سیاه!

جایی ک%ه معم%اران خ%وب ب%ر س%ر آن تواف%ق ندارن%د >>>> چیزه%ایی

هس%ت اینج%ا در و ج%البی ط%راحی) عی%وب (گ%اهی

ریسک ها کمک می کند.یافتن ابهام و ناسازگاری تحلیل ابهام ها به

Page 18: توسعه  امن نرمافزار

18

تحلیل ضعف ها-3هدف: فهم اثر وابستگی های خارجی نرم افزار.نرم‌افزار‌دیگر‌یکپارچه‌توسعه‌داده‌نمی‌شود:ضعف‌در‌این‌اجزا‌

بسته‌های‌خارجی‌برای‌تامین‌ویژگی‌های‌امنیتی

چارچوب‌های‌مختلف‌

توپولوژی‌های‌مختلف‌شبکه‌

سکوهای‌نرم‌افزاری

وسایل‌ذخیره‌سازی‌مثل‌‌(محیط‌فیزیکی‌USBو‌یا‌‌iPod)ها

)...محیط‌ساخت‌)کامپایلر‌مسموم،‌ماشین‌سازنده‌آلوده‌به‌روت‌کیت‌و‌

.تجربه‌باالی‌کار‌با‌کتابخانه‌ها،‌سیستم‌های‌مختلف‌و‌سکوها‌برای‌این‌تیم‌با‌ارزش‌استمتاسفانه‌نرم‌افزار‌خاصی‌به‌این‌منظور‌وجود‌ندارد‌:مثال‌هایی‌از‌مسائلی‌که‌دراین‌تحلیل‌می‌تواند‌روشن‌شود‌

عدم‌موفقیت‌مرورگر‌یا‌هر‌جعبه‌شنی‌مجازی‌

پشتیبانی‌سرویس‌نا‌امن‌RMIو‌‌COM

واسط‌های‌دیباگ‌همان‌اندازه‌مفید‌برای‌حمله‌کننده‌که‌برای‌توسعه‌دهنده!‌خطاها‌را‌برای‌)سوء(کاربرانتان‌نفرستید!

‌)ویژگی‌های‌استفاده‌نشده‌)ولی‌ممتاز

)‌‌...حمالت‌میانی‌جعل‌کارخواه‌و‌مرد‌میانی،‌مسیرهای‌جعلی‌به‌کتابخانه‌ها‌و‌

Page 19: توسعه  امن نرمافزار

جمع بندی19%%

دش%وار کمی کلی تحلی%ل این

>>> در عم%ل ب%ه نظ%ر میرس%د

نباید چندان سخت باشد.

با چ%یزی ش%بیه م%دل STRIDE

شروع کنید

لیس%ت های چ%ک از هم شما

اس%%%تفاده حمالت الگ%%%وی

کنی%د>>>> حمل%ه کنن%ده ها ن%یز

همین کار را می کنند.

Page 20: توسعه  امن نرمافزار

20

)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.

1ایده های مقایسه معمارانه

(1تهدیدمبنا و بر اساس سناریو های سوء کاربرد( ایده‌اصلی‌:‌‌معماری‌های‌مختلفی‌می‌توانند‌نیازمندی‌ها‌را‌ارضا‌

کنند>>>‌نیاز‌به‌انتخاب‌امن‌ترین‌معماری‌مرحله‌ای4یک‌رویکرد‌‌

تحلیل‌نیازمندی‌به‌صورت‌تهدید‌مبنا‌1.

تجزیه‌کاربرد‌2.

سناریوهای ارائه‌معماری‌های‌کاندیدا‌و‌ارزیابی‌آن‌ها‌بر‌اساس‌3.کاربرد و سوء کاربرد

انتخاب‌یک‌معماری‌امن‌نهایی4.

خارج از مباحث کتاب چرخه مک گرا

Page 21: توسعه  امن نرمافزار

21

)2(Gennari,‌Jeffrey,‌and‌David‌Garlan.‌Measuring Attack Surface in Software Architecture.‌Technical‌Report‌CMU-ISR-11-121,‌Carnegie‌Mellon‌University,‌2012.

2ایده های مقایسه معمارانه )2- بر اساس اندازه گیری کمی سطح حمالت در طراحی انجام شده (2

معرفی سه تایی نشان دهنده سطح حمله در زمان طراحی بر اساس معیار Damage-Effort Ratio (DER) میزان جذابیت هر منبع برای حمله کننده و

پتانسیل حمله بدان

:

DER m میزان حقوقی که برای دسترسی به منبع الزم) privileges/access rightsاست(

DER c میزان محدودیتی که پروتکل بر روی داده های منتقل شده روی کانال اعمال می کند.

DER I پتانسیل حمله ای که به دلیل وجود داده های غیر معتمد در سیستم به وجود می آید.

-محاسبه این معیارها برای نقاط ورودی و خروجی در دیاگرام جریان برنامه طراحی شده

خارج از مباحث کتاب چرخه مک گرا

Page 22: توسعه  امن نرمافزار

جلسه آین%%%ده22

از جالب ترین مباحث!•

تست نف%%%%%%%%%وذ•


Related Documents