تکنیک‌های تست نفوذپذیری- روش DREAD از گروه Rapid7

سلام

Rapid 7 Video: Penetration Testing Techniques – DREAD Methodology

در ودکست گروه رپید ۷ با نام «وایت‌بردهای چهارشنبه» روی موضوع DREAD کار می‌کنیم. از این روش به عنوان روش و سیستم «گزارش‌دهی» در  هر تست نفوذ استفاده می‌کنیم. Rene Aguero روش DREAD را معرفی کرده و دلیل این که هر هکری باید در تست‌های نفوذ برای ارائه گزارش از این روش استفاده کند را عنوان می‌کند.

یادمون باشه که گروه رپید۷ جزو بزرگ‌ترین گروه‌های هکینگ دنیا شناخته می‌شن و فریم‌ورک متااسپلوییت رو هم اون‌ها نوشتند. پس خوبه که با استانداردهای اونا آشنا شیم

وقتی برای جایی «تست نفوذ» انجام می دهیم می خواهیم مطمئن شویم که تمام کار های انجام شده، حتی مواردی که به صورت دستی انجام داده ایم را گزارش می کنیم.

درصدی از خروجی های تست نفوذ، از ابزارهای خودکار به دست می آید. اما مطلوب ما این است که درصد مربوط به ابزارهای خودکار به ۱۰٪ الی ۱۵٪ و موارد مربوط به روش ها و ابزار های دستی (manual) به  ۸۵٪‌ تا ۹۰٪ برسد. زمانی که به بررسی یافته‌های‌مان می‌پردازیم، می گوییم: «خوب، من این هاست رو مورد آزمایش قرار دادم و تونستم این نوع از اطلاعات رو از اون به دست بیارم». بنابراین در این مرحله به روشی خوب و استاندارد جهت مرتب سازی و دسته بندی یافته‌ها احتیاج داریم.

و این جا، همان جایی است که روش DREAD وارد بازی می شود. [تمدن: حرف D مخفف Damage Potential، حرف R مخفف Reproducability، حرف E مخفف Exploitability، حرف A مخفف Affected Users و حرف D مخفف Discoverablity می باشد که توضیحات آن را در ادامه آورده‌ام] وقتی به یک نقطه ی آسیب پذیر می رسیم، واقعا باید در مورد چه موضوعی صحبت کنیم؟  Damage Potential یا میزان خسارت این آسیب پذیری و تاثیری که به سازمان وارد می کند به چه اندازه است؟ یک نفوذگر حرفه ای می گوید: من این آسیب پذیری را پیدا کرده ام و این رخنه چه خسارت هایی را به سازمان شما یا دپارتمان IT شما یا تیم امنیتی شما و یا قسمت‌های دیگر وارد می کند.

مشکل دیگری که واقعا بزرگ است مربوط به Reproducability یا قابلیت انتشار و تکثیر آن می شود. آیا می توانم از بیرون سازمان آن را تولید کنم؟ آیا کسی که مهارت های خیلی خاصی هم ندارد (همان هایی که اسم هکر را روی خود گذاشته اند!!) هم می توانند در بیرون از سازمان و با استفاده از این آسیب پذیری آن را اکسپلوییت کنند؟

موضوع دیگر، Exploitablity یا قابلیت اکسپلوییت شدن آن است. آیا قبلا، اکسپلوییتی برای این آسیب پذیری نوشته شده است؟ آیا به وسیله‌ی این اکسپلوییت می توان از خارج سازمان یک نشست درون سیستم ایجاد کرد و نفوذ را از آن طریق انجام داد؟

موضوع بعدی مشخص می کند که در صورت اجرایی شدن این آسیب پذیری یا رخنه چه تعدادی از کاربران تحت تاثیر قرار می گیرند. (Affected Users)

و مورد آخر اینکه اگر کسی به سیستم نفوذ کند؛ آیا مثل یک پروازی می ماند که از دید رادارها مخفی است و به راحتی می تواند همه چیز را به سرقت ببرد؟ و یا قابلیت شناسایی آن برای سازمان وجود دارد. (Discoverability)

پس ما به دنبال شاخص و روشی هستیم که به ازای تمام یافته هایمان، این موارد را گزارش کند.

مورد بعدی که در تست های نفوذپذیری مهم است، بحث «انتقال دانش» است. بعضی اوقات زمانی که شما -به عنوان نماینده ی سازمان و نه نفوذگر- یک تست نفوذ انجام می دهید، نفوذگر به شما اطلاعات زیاد و مختلفی می دهد و وقتی می گویید : «این ها واقعاً عالی اند؛ این ها را از کجا پیدا کرده ای؟» در اکثر مواقع نفوذگر فکر می کند که دانش او مثل «دستور تهیه‌ی یک سس مخفی و خوشمزه» می ماند و چیزی را با شما به اشتراک نمی گذارد و ممکن است در جواب شما بگوید: «از روش های بسیار پیچیده و مختلفی استفاده کرده ام…» بنابراین در یک «تست نفوذ» هکر باید تمام مواردی که انجام داده است را با شما به اشتراک بگذارد و مشخص کند که «من از این ابزارها استفاده کرده ام؛ این دستورات را اجرا کرده ام؛ این کاری بود که انجام داده ام و اگر بخواهید می توانید خودتان آن را انجام دهید…»

هدف از این کار، این نیست که شما یک هکر شوید. تنها می خواهیم به لایه های روشن تری از داده هایی که به دست آمده برسیم. شما می توانید خودتان آن را انجام داده و آن را بازتولید کنید. بنابراین زمانی، یک تست نفوذ خوب خواهد بود که از روش DREAD استفاده شده و مشخص شود که یافته های آزمایش واقعا چگونه به دست آمده است…

پیاده سازی و ترجمه به فارسی توسط تمدن و در ۶ مرداد ۱۳۹۳