مرور کد

Download Report

Transcript مرور کد

‫بسم هللا الرحمن الرحیم‬
‫جلسه دوم‬
‫‪2‬‬
‫‪‬‬
‫سه ستون امنیت نرمافزار معرفی شد‪.‬‬
‫‪‬‬
‫در ادامه‪ :‬شرح ستون اول و دوم‬
3
‫‪ ‬اتفاق نظر همـــه روی این گــــــــزاره‬
‫‪‬‬
‫<<<<<امنیت یـــعنی مدیریت ریسک‬
‫زبانهای مختلف در بیان همین گزاره! << مدیریت ریسک ~ تحلیل ریسکــ~ مدل تهدید‬
‫‪ ‬فرآیند مدیریت ریسک مداوم و پیوسته ‪ ،‬یـــک ضـــرورتــــــ‬
‫‪‬‬
‫‪ RMF‬یک فعالیت در تمام طول چرخــه حیاتــــــــ چه پروژههای کوچک‪ ،‬چه پروژههای بزرگـــــ‬
‫‪ RMF ‬یک چارچوب مدیریت ریسک کـــــلی ( نه تنها برای ریسکهای امنیتی نرم افزار‪ ،‬بلکه برای‬
‫موقعیتهای غیر نرمافزاری)‬
‫‪‬‬
‫ایده اصلی ‪ ::‬شناسایی‪ ،‬رتبهبندی‪ ،‬پیگیری و درک‬
‫ریسک امنیت نرمافزار با توجه به تغییرات در‬
‫طول زمان‬
‫‪ ‬ارزیابی و توصیف تاثیرات‪ ،‬مرکزیت توجه مدیریت ریسک‬
‫‪ ‬خستهکننده بودن شناسایی ریسکهای جدی برای افراد فنی <<< توصیف آثار برای این افراد‬
‫‪ RMF ‬برای یک پروژه کوچک <<< یک عضو نیمهوقت در تیم‬
‫‪4‬‬
‫‪ 5‬مرحله اصلی‬
‫تعریف استراتژی‬
‫کاهش ریسک‬
‫در طی یک فرآیند حلــقهبســــته‬
‫جمعآوری و اولویتبندی‬
‫ریسکها‬
‫شناسایی ریسکهای تجاری و تکنیکی‬
‫فهم زمینه تجارت‬
‫انجام اقدامات مورد نیاز و اعتبارسنجی‬
‫‪5‬‬
‫‪ ‬شناخت زمینه تجاری و اهداف برتر تجاری در آن‬
‫زمینه خاص از طریق ‪:‬‬
‫‪ ‬جمعآوری مصنوعات (شامل معماری سیستم‪ ،‬حساب‬
‫های کاربری‪،‬‬
‫مجوزها‪ ،‬محیطهای تعریف شده‪،‬‬
‫مصنوعات نرمافزاری‪ ،‬مستندهای تولید شده به صورت‬
‫خودکار‪ ،‬دادهها و ‪)...‬‬
‫‪ ‬انجام بررسی درباره پروژه ( به دست آوردن یک‬
‫خالصه تک صفحهای <<<‬
‫جنگل! )‬
‫‪6‬‬
‫دید کلی‬
‫برای دیدن‬
‫‪‬‬
‫اهداف تجاری ‪ ::‬ذاتا مبهم‪ ،‬عدم تبیین صریح‬
‫‪ ‬اهداف تجاری شامل افزایش در آمد‪ ،‬ارضای توافقنامههای تجاری(‪،)SLA‬‬
‫بازگشت سرمایه(‪)ROI‬‬
‫‪‬‬
‫ریسک تجاری ‪ ::‬به خطر افتادن هریک از اهداف تجاری از قبیل‬
‫ضررهای مالی‪ ،‬تخریب نام و آبروی تجاری و یا نقض حقوق مشتریان یا‬
‫محدودیتهای قانونی‬
‫‪‬‬
‫ریسک فنی ‪ ::‬موقعیتی بر خالف طرح یا پیادهسازی برنامهریزی شده‬
‫سیستم مورد نظر‬
‫‪ ‬شناسایی ریسکهای فنی و نگاشـــت آنها به ریسکهای تجــاری‬
‫>>>> فعالیت اصلی‬
‫‪7‬‬
‫‪‬مطرح بودن تعداد زیادی از ریسکها برای هر سیستمی<<<‬
‫صرف شناسایی اهمیت دارد اما ‪ .....‬اولویت بندی به آنها‬
‫ارزش می بخشد‬
‫‪‬اولویتبندی با توجه به اهداف تجاری مهمتر‬
‫‪ ‬معیارهای مربوط به ریسک شامل‬
‫‪ ‬احتمال ریسک‬
‫‪ ‬اثر ریسک‬
‫‪ ‬شدت ریسک‬
‫‪ ‬تعداد ریسکهای نوظهور و یا کاهش یافته در زمان‬
‫‪ ‬امکان خودکارسازی جمعآوری و نمایش این معیارها‬
‫‪8‬‬
‫‪ ‬تحلیلگران فنی ‪::‬‬
‫‪ o‬توانا در کشف مشکالت فنی‬
‫‪ o‬ناتوان در تعیین آنچه باید انجام گیرد‬
‫‪ ‬هیچ کس نمیخواهد تنها صورتی از مشکالت بدون راه حل را‬
‫بشنود!‬
‫‪ ‬محکـــــ یک تحلیل ریسک با قوت راهبرد کاهش ریسک آن‬
‫‪ ‬شکستن همیشه ساده تر از ساخت چیزی ناشکستنی‬
‫‪ ‬لزوم در نظر گرفتن معیارهای تجاری مثل هزینه تخمینی‪ ،‬بازگشت‬
‫سرمایه‪ ،‬اثربخشی روش و درصد پوشش ریسک‬
‫‪9‬‬
‫‪ ‬اعتبارسنجی این امر که ریسکهای غیرقابل پذیرش‪،‬‬
‫مصنوعات نرمافزاری و فرآیندها را تهدید نمی کند‪.‬‬
‫‪ ‬این فرآیند اعتبار سنجی باید یک رویه قابل تکرار‪،‬‬
‫قابل اندازهگیری و قابل وارسی باشد تا مرتبا جهت‬
‫وارسی کیفیت مصنوعات قابل استفاده باشد‪.‬‬
‫‪10‬‬
‫‪11‬‬
‫‪‬‬
‫اهمیت اندازه گیری در هر حوزه دانش‬
‫‪‬‬
‫«وقتی شما میتوانید آنچه را میگویید اندازه بگیرید و در قالب اعداد آن‬
‫را بیان کنید‪ ،‬درباره آن پدیده مقداری میدانید‪ .‬وقتی نمی توانید با اعداد‬
‫آن را بیان کنید چنان دانشی را ندارید و در حقیقت شاید مقدمه دانش مورد‬
‫نیاز را داشته اید اما ‪»....‬‬
12
‫ ؟‬RMF ‫چرا‬

‫چارچوب های دیگر مدیریت ریسک با نگاهی متمرکز تر بر امنیت نرمافزار‬

‫میشناسید؟‬
:‫راهنمایی‬
1.

SSTRM
http://web.securityinnovation.com/software-
security-total-risk-management/
2.
http://technet.microsoft.com/enus/library/cc163143.aspx
13
‫‪14‬‬
‫توسعه امن نرمافزار‬
‫دکتر رسول جلیلی‬
‫‪15‬‬
‫توسعه امن نرمافزار‬
‫دکتر رسول جلیلی‬
16
‫‪‬‬
‫دستورالعملهای صریح و مشخص به منظور‬
‫دخیل کردن مهندسی امنیت در نیازمندیها‪،‬‬
‫معماری‪ ،‬طراحی‪ ،‬کدزنی‪ ،‬اندازهگیری و نگهداری‬
‫‪‬‬
‫معرفی شده در قالب مراحل و نقاط مشخص و‬
‫قابل لمسی با نام ‪Touchpoint‬‬
‫‪‬‬
‫اجرای چرخهای و متناوب مراحل‬
‫‪‬‬
‫قابل اعمال بودن این مراحل به هر فرآیند تولید‬
‫نرمافزار‬
‫‪‬‬
‫قابلیت استفاده از این مراحل در شرایط که حداقل‬
‫مجموعه مصنوعاتی وجود داشته باشد هر‬
‫پروژهای حداقل یک مصنوع کد را دارد‪.‬‬
‫‪‬‬
‫‪17‬‬
‫اولویت برخی مراحل بر دیگران‬
‫مراحل شامل ‪:‬‬
‫‪(1‬‬
‫مـــرور کــــــد‬
‫‪(2‬‬
‫تحلیللللللللللللللللللل ریسللللللللللللللللللک‬
‫معــــــمارانـــه‬
‫‪(3‬‬
‫تســتـ نفـــــوذ‬
‫‪(4‬‬
‫تسللللللللللللللتهای امنیتللللللللللللللی‬
‫ریــــسکمبـــنا‬
‫‪(5‬‬
‫سناریوهای سوء کاربرد‬
‫‪(6‬‬
‫نیازمندیهای امنیتی‬
‫‪(7‬‬
‫اقدامات اپراتوری امنیت‬
‫‪‬‬
‫سوال؟‬
‫‪‬‬
‫ناهماهنگی در ترتیب تصویر و لیست معرفی شده‬
‫مشاهده نمیشود؟‬
‫‪18‬‬
‫‪‬‬
‫جواب؟‬
‫‪‬‬
‫در ادامه ‪!...‬‬
‫‪19‬‬
‫‪ ‬مثال ‪ ::‬سرریز بافر در خط ‪ 42‬کد‬
‫‪ ‬ابزارهای مختلف تحلیل ایستا برای پویش کد‬
‫منبع به منظور یافتن آســـیبپذیـــری‬
‫‪ ‬الزم ولـــــــی نـاکافــــی‬
‫‪ ‬بـرطرفــــ شــدن ‪ ٪50‬نقصهـــا‬
‫‪20‬‬
‫‪‬‬
‫‪‬‬
‫مصنــــوع مورد نظر در این مرحله ‪ :‬مشخصات سیستم و طراحی آن‬
‫طراحان‪ ،‬معماران وتحلیلگران <<<مستندسازی مفروضات به گونهای‬
‫صریح‪ ،‬که شناسایی حمالت ممکن باشد‪.‬‬
‫‪‬‬
‫تحلیلگران امنیت <<< شناسایی و رتبهبندی عیوب معمارانه به منظور آغاز‬
‫رویه کاهش ریسک‬
‫‪‬‬
‫مثال ‪:‬‬
‫‪ o‬افراز نامناسب و محافظت ضعیف از دادههای حساس‬
‫‪ o‬ناتوانی وبسرویس از احراز اصالت کد فراخوانیشده و کاربر آن؛‬
‫‪ o‬دخیل نبودن زمینه متناسب در اتخاذ تصمیمات کنترل دسترسی‬
‫‪21‬‬
‫‪‬‬
‫مصنوع این مرحله ‪ :‬سیستم در محیط عملیاتی خود‬
‫‪‬‬
‫مثال ‪::‬اداره ضعیف وضعیت برنامه در واسط وب‬
‫‪‬‬
‫درک درستی از نرمافزار در محیط عملیاتی‬
‫‪ ‬دخیل نکردن معماری نرمافزار در آزمون <<<ممکن است‬
‫ریسکهای نرمافزار را آشکار نکند‬
‫‪‬‬
‫نوعی تست جعبه سیاهی‬
‫‪‬‬
‫شکست در اینگونه آزمون به معنای مشکل جدی در پروژه‬
‫‪‬‬
‫یک خطر درباره آزمون نفوذ<<< کسانی که آن را انجام میدهند!!‬
‫‪‬‬
‫هکرهای تواب!‬
‫‪22‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫مصنوع این مرحله ‪ :‬بخشهای سیستم و نیز کل آن‬
‫مثال ‪ :‬وسعت نشت دادهها‬
‫‪ 2‬راهبرد‪:‬‬
‫‪ ‬آزمون کارکردهای امنیتی با تکنیکهای آزمون کارکردی‬
‫استاندارد‬
‫‪ ‬آزمون امنیتی بر اساس الگوی حمالت‪ ،‬نتایج تحلیل ریسک و‬
‫سناریوهای سوء کاربرد‬
‫یک برنامه آزمون مناسب شامل هردو راهبرد‬
‫تفاوت با تضمین کیفیت ‪::QA‬‬
‫تضمین کیفیت یعنی تضمین وقوع اتفاقات درست و خوب‬
‫آزمون امنیتی یعنی تضمین عدم وقوع اتفاقات بد!‬
‫‪‬‬
‫ضرورت وجود رویکردی شبیه حملهکنندگان‬
‫‪23‬‬
‫‪‬‬
‫مصنوع این مرحله ‪ :‬نیازمندیها و سناریوهای کاربرد‬
‫‪‬‬
‫نمونه ریسک‪ :‬ضعف در قبال حمالت شناخته شده دستکاری داده‬
‫‪‬‬
‫تولید سناریوهای سوءکاربرد یک راه مناسب برای تقریب به ذهن‬
‫حملهکننده‬
‫‪‬‬
‫شبیه سناریوی کاربرد(‪ ،)use cases‬رفتار برنامه را در شرایط‬
‫حمله نشان میدهد‪.‬‬
‫‪‬‬
‫لزوم پاسخ صریح به اینکه ‪ ::‬چه چیزی‪ ،‬از چه کسی و تا چه زمانی‬
‫باید محافظت شود؟‬
‫‪24‬‬
‫‪ ‬مصنوع این مرحله ‪ :‬نیازمندیها‬
‫‪ ‬نمونه ریسک‪ :‬عدم وجود هیچ توصیفی درباره نیازهای حفاظت از دادهها‬
‫‪ ‬امنیت باید به صورت صریح در سطح نیازمندیها منعکس شود‪.‬‬
‫‪ ‬پوشش داده شدن ‪ 2‬مورد در نیازمندیهای امنیتی خوب‬
‫‪ ‬امنیت به صورت کارکرد مشخص ( مثل اعمال رمزنگاری)‬
‫‪ ‬ویژگیهای امنیتی ضمنی ( با توجه به الگوی حمالت وسناریوهای سوء‬
‫کاربرد)‬
‫‪ ‬هنــر شناسایی و حفظ نیازمندیهای امنیتی‪ ،‬پیچیده و نیازمند تالش گسترده‬
‫‪25‬‬
‫‪‬‬
‫مصنوع این مرحله ‪ :‬سیستم تحویل داده شده و قرارگرفته در‬
‫میدان‬
‫‪‬‬
‫نمونه ریسک‪ :‬دادههای ممیزی ناکافی برای پیگرد حملهکننده‬
‫‪‬‬
‫تشویق متخصصان امنیت شبکه به شرکت در رویه اعمال فرآیند‬
‫معرفی شده‬
‫‪‬‬
‫وقوع حمله مستقل از قوت طراحی وپیاده سازی<<< فهم‬
‫رفتاری از نرمافزار که موجب موفقیت یک حمله شده است یک‬
‫رویه دفاعی ضروری خواهد بود‪.‬‬
‫‪‬‬
‫دانش به دست آمده از حمالت و اکسپلویتها باید به تیم و فرایند‬
‫توسعه نرمافزار بازخورد دهد‪.‬‬
‫‪ ‬یکسان نبودن ترتیب مراحل برای همه سازمانها‬
‫‪ ‬توجه ترتیب بیان شده به کدگرایی سازمانها <<<مرور کد قبل از‬
‫تحلیل ریسک معمارانه‬
‫‪ ‬نقص(‪)defect‬های نرمافزاری‪::‬‬
‫‪ o‬اشکاالت(‪ <<<<)bugs‬مرور کد‬
‫‪ o‬عیوب (‪ <<<<)Flaws‬تحلیل ریسک معمارانه‬
‫‪ ‬ضروری بودن هر دو مرحله فوق‪ ،‬انجام ندادن هر یک از‬
‫آنها<<<< باقی ماندن نیمی از نقصها‬
‫‪ ‬ترتیب مراحل نشان دهنده رویکرد واکنشی در امنیت‬
‫‪26‬‬
‫‪27‬‬
‫‪‬‬
‫تحلیل خارجی‪::‬تحلیل توسط فردی خارج از تیم طراحی‬
‫‪‬‬
‫غالبا از دید امنیت مورد نیاز است‬
‫‪‬‬
‫با اینکه یک مرحله اساسی مثل بقیه مراحل نیست‪،‬‬
‫<<<<اهمیت باالیی دارد‪.‬‬
‫‪‬‬
‫اعمال همه مراحل توسط فردی که در طراحی و پیادهسازی‬
‫سیستم نبوده است‬
‫‪‬‬
‫نیاز به دو کاله سفید و سیاه‬
‫‪‬‬
‫کاله سیاه رویکرد مخرب به منظور حمله‪،‬‬
‫اکسپلویت و ‪...‬‬
‫‪‬‬
‫کاله سفیدی رویکردی سازنده برای طراحی و‬
‫دفاع‬
‫‪‬‬
‫‪‬‬
‫دشواری یافتن راه حل نیاز دوگانه دفاع و حمله‬
‫خوب یا بد نبودن هیچ یک از مفاهیم دفاع یا حمله‬
‫‪ ‬ترکیبی از دو رویکرد در چرخه‬
‫‪28‬‬
‫‪‬‬
‫مرور کد <<< رویکرد کاله سفیدی و سازنده برای اجتناب از‬
‫مشکالت پیادهسازی‬
‫‪29‬‬
‫‪‬‬
‫تحلیل معمارانه ریسک <<<< رویکرد کاله سفیدی برای‬
‫اجتناب از عیوب طراحی‬
‫‪‬‬
‫تست نفوذ<<<< فعالیتی کاله سیاهی و مخرب ‪ .‬در بهترین‬
‫نوع با ترکیب دانش کاله سفیدی از طراحی و ریسکهای‬
‫مربوط به آن‬
‫‪‬‬
‫سناریوهای سوء کاربرد<<< باز هم ترکیبی ولی بیشتر کاله‬
‫سیاهی‬
‫نیازمندیهای امنیتی <<<کاله سفیدی و سازنده برای دفاع‬
‫علیه دنیای کاله سیاهها‬
‫‪‬‬
‫اپراتوری امنیتی <<<یک فعالیت کاله سفیدی اما کمتر سازنده‬
‫است‬
30
‫‪‬‬
‫همانطور که در بسیاری از سازمانها دیده میشود<<<< امنیت‬
‫نرمافزار کار هیچ فردی نیست!‬
‫‪‬‬
‫نا آگاهی اغلب توسعهدهندگان‪ ،‬معماران و دیگر سازندگان از امنیت‬
‫‪‬‬
‫عدم پاسخگویی و مسئولیتپذیری به دلیل ناآگاهی<<< پاس دادن مشکل‬
‫به اپراتورها برای نصب یا استفاده نا مناسب از نرمافزار‬
‫‪‬‬
‫باور غلط مرتبط بودن امنیت تنها با افراد حوزه فا و نامرتبط با‬
‫نرمافزار‬
‫‪‬‬
‫در حالت ایده آل<<< امنیت نرمافزار وظیفه همه است‬
‫‪‬‬
‫در ایدهای واقعگرایانهتر<<< انتساب مسئولیت به یک گروه خاص‬
‫مشکل را تا حد زیادی حل خواهد‪31‬کرد‬
‫‪ ‬زمان منتظر محیطهای آکادمیک نمیماند‬
‫‪ ‬لزوم تربیت امنیتکاران نرمافزار در سازمانهای فعلی‬
‫‪ ‬چند توصیه ‪::‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫با افراد امنیتی آغاز نکنید!‬
‫امنیت شبکه کاران معموال به حد کافی درباره نرمافزار نمیدانند‬
‫با افراد نرمافزاری آغاز کنید‪:‬‬
‫امنیت سادهتر از نرمافزار آموخته میشود!‬
‫افراد نرمافزاری ماهر بسیار با ارزشند و باید در سازمان باقی بمانند‬
‫استفاده از مشاوران خارج از سازمان برای کمک به تشکیل اولیه‬
‫یک گروه امنیتی‬
‫تشکیل یک گروه امنیتی با دو رویکرد کاله سفیدی و کاله سیاهی‬
‫اگر بتوانید افرادی را پیدا کنید که بتوانند هر دو کاله را داشته‬
‫باشند‪....‬‬
‫‪ ‬تمایز میان سازندگان و ممیزان‪ ،‬سازندگان اهمیت بیشتر دارند‪.‬‬
‫‪32‬‬
‫‪33‬‬
‫•‬
‫آغاز مرحلــه مرور کـــــد‬
‫•‬
‫با رویکــــردی عمـــلیتر‬