در این بخش به تفصیل درباره چگونگی آماده‌سازی سازمان خود برای راه‌اندازی و اجرای یک برنامه افشای آسیب‌پذیری موفق، از جمله توصیه‌های عملی در مورد نحوه پر کردن شکاف‌هایی که شناسایی کرده‌اید، بحث خواهیم کرد.
پیدا کردن اشکالات
تقویت برنامه امنیتی موجود خود با محققان امنیتی خارجی یک راه عالی برای یافتن مسائل پیچیده و آسیب پذیری های مبهم است. با این حال، استفاده از یک VDP برای یافتن مشکلات امنیتی اساسی که می‌توانند در داخل کشف شوند، اتلاف منابع است.
مدیریت دارایی
وقتی نوبت به یافتن اشکالات می رسد، تنها راه برای دانستن اینکه از کجا شروع کنید این است که ایده خوبی از آنچه در خارج وجود دارد داشته باشید. شما می‌توانید صد ابزار امنیتی بخرید، اما اگر تیم‌ها برنامه‌ها، سیستم‌ها و سرویس‌ها را به طور موقت و بدون اطلاع شما آماده کنند، فرقی نمی‌کند، به خصوص اگر راهی برای کشف و انجام ارزیابی‌های امنیتی در برابر این ابزارها نداشته باشید. دارایی های. با افراد و تیم‌هایی که مسئول کمک به ایجاد برنامه‌ها، سیستم‌ها و سرویس‌های جدید هستند، بررسی کنید تا ببینید آیا آنها فرآیندی برای ایجاد و نگهداری فهرستی از مواردی که در حال چرخش هستند و مالک آنها هستند یا نه. اگر روند فعلی وجود نداشته باشد، این یک فرصت عالی برای همکاری با این تیم ها برای ساختن آن است. به دست آوردن درک درستی از دارایی های سازمان شما بهترین نقطه برای شروع هنگام شناسایی سطح حمله است. به عنوان بخشی از این فرآیند، تیم امنیتی باید در توسعه پیاده‌سازی زیرساخت جدید برای ارائه بررسی‌های امنیتی مشارکت داشته باشد. داشتن موجودی گسترده ای از دارایی ها و مالکان، تمرین خوبی است. این نوع موجودی هنگام اعمال وصله‌های جدید که نیاز به خاموش شدن موقت سیستم‌های خاصی دارند، مفید است. این یک نقشه راه از افراد یا تیم هایی است که نیاز به اطلاع رسانی دارند و سیستم هایی که تحت تأثیر قرار می گیرند. وجود یک فرآیند مدیریت دارایی قوی، تضمین می‌کند که مالکان زودتر در فرآیند شناسایی می‌شوند، به‌طور منظم به‌روزرسانی می‌شوند و همه سیستم‌ها در سراسر سازمان طبق برنامه عمل می‌کنند.
علاوه بر مدیریت فعال دارایی، در نظر بگیرید که چه اقدامات واکنشی را می توانید برای شناسایی دارایی هایی که به سازمان شما تعلق دارند، اما از شکاف های فرآیندهای استاندارد مدیریت دارایی شما عبور کرده اند، اجرا کنید. این می‌تواند شامل استفاده از فرآیندهای شناسایی مشابهی باشد که توسط محققان امنیتی استفاده می‌شود که در VDPها و برنامه‌های پاداش باگ شرکت می‌کنند. برای مثال، می‌توانید از ابزارهای رایگان و منبع باز استفاده کنید که محدوده‌های IP یا دامنه‌هایی را که ممکن است متعلق به سازمان شما باشد، اسکن و شمارش کنند. جستجوی Google برای بازیابی پاداش اشکال ، نکات و ترفندهای مختلفی را ارائه می‌کند تا به شما کمک کند دارایی‌هایی را از سازمان خود شناسایی کنید که از آنها بی‌اطلاع هستید.
اسکن آسیب پذیری اساسی
اکنون که پایه محکمی در مورد جایی که باید مسائل امنیتی را پیدا کنید دارید، بیایید به نحوه انجام این کار بپردازیم. سطوح مختلفی از عمق وجود دارد که می توانید بسته به منابع سازمان خود به آن ها بپردازید، اما باید از طریق برنامه افشای آسیب پذیری خود تعادلی بین تلاش های امنیتی داخلی خود و جامعه هک خارجی پیدا کنید. این تعادل برای هر سازمانی بسته به منابع موجود متفاوت است.
ابزار خود را انتخاب کنید
ابزارهای مختلفی برای کمک به شناسایی آسیب پذیری ها وجود دارد. برخی از ابزارهای اسکن آسیب پذیری به صورت رایگان در دسترس هستند، در حالی که برخی دیگر هزینه دارند. تشخیص اینکه چه ابزارهایی را انتخاب کنید به نیازهای فردی شما بستگی دارد.
- الزامات سازمان شما
- هر ابزار چقدر این الزامات را برآورده می کند
- اگر مزایای ابزار بیشتر از هزینه ها باشد (مالی و اجرایی).
می‌توانید از این الگوی الزامات ( OpenDocument.ods ، Microsoft Excel.xlsx ) برای ارزیابی ابزارهای مختلف بر اساس نیازهای خود استفاده کنید. برخی از الزامات نمونه در قالب گنجانده شده است، اما باید با تیم های امنیتی، فناوری اطلاعات و مهندسی خود صحبت کنید تا قابلیت های مورد نیاز را هماهنگ کنید. قبل از راه‌اندازی یک برنامه افشای آسیب‌پذیری، حداقل، باید بتوانید اسکن آسیب‌پذیری را در برابر هر دارایی خارجی (مانند وب‌سایت‌ها، APIها، برنامه‌های تلفن همراه) انجام دهید. این به شما کمک می‌کند قبل از دعوت از محققان امنیتی خارجی برای آزمایش در برابر این دارایی‌ها و خدمات، آسیب‌پذیری‌های قابل کشف را پیدا کرده و آنها را برطرف کنید.
تنظیم اسکن
اسکن خودکار آسیب‌پذیری می‌تواند مشکلات زیادی را پیدا کند، اما می‌تواند نتایج مثبت کاذب نیز ایجاد کند. به همین دلیل است که قبل از به اشتراک گذاشتن نتایج با تیم های تحت تأثیر، باید منابعی برای تأیید اعتبار داشته باشیم. شما باید فرآیندهایی را پیاده سازی کنید تا مطمئن شوید که اسکن ها به طور منظم اجرا می شوند و نتایج این اسکن ها واقعاً بررسی می شوند. این برای هر سازمانی متفاوت به نظر می رسد، اما حداقل، باید تعیین کنید:
- فرکانس اسکن
- مداوم
- هفتگی
- ماهانه
- کدام دارایی ها در حال اسکن هستند
- اعتبارنامه
- اسکن های احراز هویت شده در مقابل اسکن های احراز هویت نشده
- (نکته: اگر با اعتبارنامه اسکن نکنید ، سپس یک محقق امنیتی هنگام راه اندازی VDP خود را با اعتبار آزمایش کند، ممکن است آسیب پذیری های شناسایی شده زیادی دریافت کنید)
- نقش ها و مسئولیت ها
- اعضای تیم مسئول اجرای اسکن ها را شناسایی کنید
- در صورت لزوم یک چرخش تنظیم کنید
- نتایج را اسکن کنید
- بررسی نتایج اسکن
- ثبت باگ برای آسیب پذیری های تایید شده
- شناسایی مالکان برای رفع اشکال
- پیگیری با مالکان برای اصلاح
در بخش رفع اشکالات بعداً در این راهنما به جزئیات بیشتری در مورد چگونگی اطمینان از رفع مشکلات امنیتی شناسایی شده خواهیم پرداخت.
فرآیند بررسی امنیتی
در حالی که اسکن آسیب پذیری یک راه عالی برای شناسایی واکنشی مسائل امنیتی در سازمان شما است، پیاده سازی فرآیندهای بررسی امنیتی می تواند به جلوگیری از معرفی آسیب پذیری ها در وهله اول کمک کند. برای هدف این راهنما، اصطلاح بررسی امنیتی به هر موقعیتی اشاره دارد که باعث بازبینی دستی توسط یکی از اعضای تیم امنیتی شما شود. به طور معمول، این شامل داشتن اختیار برای جلوگیری از تغییر در صورتی که خیلی خطرناک تلقی شود، می شود. اگر تیم امنیتی شما توانایی مسدود کردن تغییرات مخاطره آمیز را ندارد، همچنان می خواهید فرآیندهایی برای مستندسازی خطر داشته باشید. این می تواند به اطمینان حاصل شود که هر کسی که برای تغییر فشار می آورد، خطر مربوط به آن را می داند و فعالانه آن ریسک را می پذیرد.
معیارهای بررسی امنیتی
بررسی های امنیتی چه زمانی باید انجام شود؟ ایجاد مجموعه‌ای از معیارها که بازبینی امنیتی را آغاز می‌کند به اطمینان از اینکه همه در یک صفحه هستند کمک می‌کند. در زیر چند نمونه از سناریوهایی وجود دارد که ممکن است باعث بازبینی امنیتی شود.
- عملکرد جدید مربوط به داده های حساس کاربر پیشنهاد شده است
- ویژگی جدیدی که به کاربران امکان می دهد موقعیت مکانی خود را روی نقشه به اشتراک بگذارند
- درخواست اطلاعات بالقوه حساس از کاربران، مانند آدرس منزل، تاریخ تولد، یا شماره تلفن
- به روز رسانی های عمده برای عملکرد موجود ساخته شده است
- گرفتن داده‌های کاربر موجود و استفاده از آن به روشی جدید که کاربران ممکن است انتظار نداشته باشند بدون دادن فرصتی برای انصراف
- تغییرات در هر ویژگی مربوط به احراز هویت، مجوز، و مدیریت جلسه
- تغییرات در محیط تولید شرکت
- پیکربندی شبکه تغییر می کند، به ویژه تغییراتی که ممکن است منجر به افشای خدمات خارجی شود
- نصب نرم افزار جدید که داده های حساس کاربر را مدیریت می کند، که در صورت به خطر افتادن می تواند به طور غیر مستقیم برای دسترسی به داده های حساس کاربر استفاده شود.
- ایستادن سیستم ها یا خدمات جدید
- تعامل با یک فروشنده جدید یا تغییر نحوه کار با یک فروشنده موجود
- راه اندازی یک فروشنده جدید که داده های حساس کاربر را مدیریت می کند
- تغییراتی در نحوه کار شما با یک فروشنده موجود که منجر به مدیریت داده های حساس کاربر توسط فروشنده می شود
این فهرست جامعی نیست، اما باید شما را به این فکر کند که چه نوع تغییراتی باید به بررسی امنیتی نیاز داشته باشد. همانطور که معیارهای نیاز به بررسی امنیتی را تعریف می کنید، آن را با سهامداران کلیدی در سراسر سازمان در میان بگذارید تا اطمینان حاصل کنید:
- ذینفعان فرصتی برای بررسی و ارائه بازخورد در مورد معیارها دارند
- ذینفعان با معیارها موافق هستند
- ذینفعان موافقت می کنند که به طور فعال درخواست بررسی های امنیتی کنند
این معیارها و همچنین نحوه درخواست بازبینی امنیتی (به عنوان مثال، ثبت یک اشکال در صفی که تیم امنیتی نظارت می کند) را مستند کنید تا سازمان شما تا حد ممکن این فرآیند را آسان کند.
منابع بررسی امنیتی
برخلاف اسکن‌های خودکار، بررسی‌های امنیتی می‌توانند منابع بیشتری را انجام دهند. هر تیم امنیتی فقط زمان زیادی در روز برای انجام کارهای بی‌شماری دارد، بنابراین باید تخمین بزنید که چه تعداد بررسی امنیتی ممکن است براساس معیارهای شما ایجاد شود. اگر متوجه شدید که تیم شما غرق شده و عقب مانده است، کسانی که منتظر راه اندازی ویژگی های آنها هستند از تیم امنیتی ناراحت می شوند. این می تواند باعث تغییر فرهنگی در سازمان شود و باعث شود که تیم امنیتی به جای شریک به عنوان یک مسدود کننده در نظر گرفته شود. اگر فرآیند بررسی امنیتی کارآمد نباشد، بسیاری از افراد و تیم ها سعی می کنند آن را به طور کامل دور بزنند. اگر منابع محدود هستند، معیارهای خود را برای نیاز به بازبینی امنیتی کاهش دهید و مایل به پذیرش ریسک باقی مانده بیشتر باشید. اگر حوادث در نتیجه کمبود منابع برای انجام بررسی های امنیتی رخ دهد، این به توجیه نیاز به منابع امنیتی بیشتر کمک می کند.
انجام بررسی های امنیتی
وقتی نوبت به تصمیم گیری در مورد بررسی های امنیتی و نحوه انجام آنها می رسد، به یک صف اولویت بندی شده نیاز دارید تا از آن خارج شوید. یک روش استاندارد برای دیگران در سازمان خود ایجاد کنید تا با هر اطلاعاتی که برای اولویت بندی مناسب آن نیاز دارید، درخواست بررسی امنیتی کنند. به عنوان مثال، پرسشنامه ای را در نظر بگیرید که شامل مواردی مانند ماهیت تغییر، از جمله خلاصه مختصری از تغییر و نوع داده های کاربر ممکن است تحت تأثیر قرار گیرد. می‌توانید به‌طور خودکار بررسی‌های امنیتی احتمالی را بر اساس پاسخ به این سؤالات به تغییرات با ریسک بالا، متوسط یا کم دسته‌بندی کنید. اگر تغییری ریسک بالایی دارد، ممکن است به یک فرآیند بررسی امنیتی عمیق‌تر نیاز داشته باشید. اگر تغییر ریسک کمتری داشته باشد، ممکن است بتوانید یک فرآیند بررسی امنیتی سبک‌تر را برای کمک به کاهش منابع مورد نیاز و سرعت بخشیدن به فرآیند و فعال کردن بهتر کسب‌وکار پیاده‌سازی کنید. یک چرخش در تیم خود راه اندازی کنید تا مسئول مدیریت صف بررسی امنیتی باشد، اطمینان حاصل کنید که بررسی های امنیتی جدید توسط اعضای تیم شما انتخاب می شود و پیشرفت بررسی های امنیتی موجود را پیگیری کنید. فرآیند واقعی بازبینی امنیتی بسته به آنچه در حال بررسی است متفاوت خواهد بود. به عنوان مثال، یک ویژگی جدید در برنامه تلفن همراه شما ممکن است به یک مهندس امنیتی نیاز داشته باشد تا کد را بررسی کرده و آسیب‌پذیری‌های احتمالی را جستجو کند. نرم افزار جدید در حال نصب ممکن است نیاز به بازبینی داشته باشد تا اطمینان حاصل شود که کنترل دسترسی به درستی تنظیم شده است. کار با فروشندگان خارجی می تواند فرآیند کاملا متفاوتی را ارائه دهد. برای مرجع، پرسشنامه ارزیابی امنیت فروشنده Google را مطالعه کنید.
رفع اشکالات
یافتن باگ ها مهم است، اما امنیت تنها پس از رفع آن باگ ها بهبود می یابد. دانستن اینکه چه خطراتی برای سازمان شما وجود دارد خوب است، اما اینکه بتوانید به طور موثر به آن ریسک رسیدگی کنید بهتر است.
مدیریت آسیب پذیری
آسیب‌پذیری‌ها از منابع مختلف، از جمله تلاش‌های داخلی (به عنوان مثال، اسکن آسیب‌پذیری و بررسی‌های امنیتی)، آزمایش‌ها و ممیزی‌های نفوذ شخص ثالث، یا حتی محققان امنیتی خارجی که قبل از راه‌اندازی رسمی VDP شما را از طریق کانال‌های پشتیبانی به شما اطلاع می‌دهند، می‌آیند. سازمان شما به روشی برای دسته بندی آسیب پذیری های جدید و موجود نیاز دارد تا اطمینان حاصل شود که آنها به ذینفعان مناسب اطلاع داده می شوند، به درستی اولویت بندی می شوند و به موقع رفع می شوند. هنگامی که VDP خود را راه اندازی می کنید، جریان جدیدی از آسیب پذیری ها را خواهید داشت که وارد فرآیندهای مدیریت آسیب پذیری شما می شوند. وجود فرآیندهای قوی برای رسیدگی به این آسیب‌پذیری‌ها به شما کمک می‌کند تا پیشرفت به سمت اصلاح را پیگیری کنید و به درخواست‌های محققان امنیتی خارجی برای به‌روزرسانی پاسخ دهید. توانایی اولویت‌بندی سریع یک آسیب‌پذیری و برقراری ارتباط با شرکت‌کنندگان VDP در مورد جدول زمانی اصلاح، تعامل با جامعه محققین امنیت را افزایش می‌دهد و همچنین اعتبار امنیت سازمان شما را بهبود می‌بخشد. بخش‌های زیر جنبه‌های مختلفی از برنامه مدیریت آسیب‌پذیری شما را که می‌خواهید قبل از راه‌اندازی VDP خود داشته باشید، تشریح می‌کند.
استانداردهای شدت و جدول زمانی اصلاح را تعیین کنید
ایجاد یک زبان مشترک در مورد شدت آسیب‌پذیری‌ها و زمان‌بندی ایده‌آل اصلاح مرتبط با هر شدت، تعیین انتظارات استاندارد با سازمان شما را آسان‌تر می‌کند. اگر با هر آسیب‌پذیری مانند یک وضعیت اضطراری برخورد شود، سازمان شما منابع خود را تمام کرده و نسبت به تیم امنیتی خشمگین می‌شود. اگر هر آسیب‌پذیری با اولویت پایین در نظر گرفته شود، آسیب‌پذیری‌ها هرگز برطرف نمی‌شوند و خطر نقض افزایش می‌یابد. هر سازمانی منابع محدودی دارد، بنابراین باید یک رتبه بندی شدت ایجاد کنید. این رتبه بندی معیارهایی را ارائه می دهد که به سازمان شما کمک می کند تا بفهمد یک آسیب پذیری در چه شدتی قرار می گیرد و زمان بندی های مورد انتظار اصلاح مربوط به هر شدت را درک کند. مجموعه ای از دستورالعمل های شدت را پیش نویس کنید و آن را برای بازخورد با سهامداران کلیدی در سازمان خود به اشتراک بگذارید. به عنوان مثال، اگر مهندسی در ایجاد استانداردهای شدت شما نقش داشته باشد، به احتمال زیاد آنها به این استانداردها می پردازند و زمانی که زمان رفع آسیب پذیری در یک بازه زمانی مشخص فرا می رسد، از آنها پیروی می کنند. این دستورالعمل‌های شدت ممکن است بسته به ریسک‌هایی که مختص کسب‌وکار شما هستند متفاوت باشد. ممکن است بخواهید یک تمرین مدل‌سازی تهدید را در نظر بگیرید تا به این فکر کنید که چه تهدیدهایی برای سازمان شما محتمل‌تر و تأثیرگذارتر هستند و نمونه‌هایی از مسائلی را که در هر دسته‌بندی شدت قرار می‌گیرند، بگنجانید. در زیر نمونه ای از استانداردهای شدت و جدول زمانی اصلاح برای یک سازمان مالی آورده شده است.
| شدت | شرح | جدول زمانی اصلاح | مثال ها) |
|---|---|---|---|
| بحرانی | مسائلی که تهدیدی قریب الوقوع برای کاربران یا کسب و کار ما ایجاد می کند. | مالک: مالک اصلی برای اطمینان از رفع آسیب پذیری باید ظرف 8 ساعت شناسایی شود. حتی در خارج از ساعات کاری عادی با منابع تماس و صفحه تماس بگیرید. رفع: این مشکل باید در اسرع وقت یا حداکثر ظرف سه روز کاری برطرف شود یا حداقل خطر کاهش یابد. | به خطر انداختن یک پایگاه داده تولید شامل تمام سوابق مالی کاربران. مهاجمی که به اسرار تجاری مانند الگوریتم های سرمایه گذاری اختصاصی ما دسترسی پیدا می کند. یک حادثه فعال شامل دسترسی مهاجم به شبکه داخلی یا سیستم های تولید حساس ما. |
| بالا | مسائلی که در صورت بهره برداری از آنها می تواند آسیب های قابل توجهی به بار آورد. | مالک: مالک اصلی باید ظرف یک روز کاری شناسایی شود. رفع: ظرف 10 روز کاری (~2 هفته). | آسیب‌پذیری‌هایی که می‌تواند منجر به دسترسی به داده‌های حساس کاربر یا عملکرد شود (مثلاً توانایی هر کاربر برای سرقت وجوه از کاربر دیگر). |
| متوسط | مسائلی که بهره برداری از آنها سخت تر است یا منجر به آسیب مستقیم نمی شود. | مالک: مالک اصلی باید ظرف پنج روز کاری شناسایی شود. رفع: ظرف 20-40 روز کاری (~1-2 ماه). | مشکلات تأیید شده شناسایی شده توسط اسکنرهای خودکار، مانند وصله های به روز رسانی امنیتی بدون سوء استفاده شناخته شده. مشکلات افشای اطلاعات که احتمالاً به حملات بیشتر کمک می کند. مسائل محدود کننده را که به طور بالقوه می توانند مورد سوء استفاده قرار گیرند رتبه بندی کنید (به عنوان مثال قادر به حدس زدن مداوم رمزهای عبور برای یک کاربر). |
| کم | مسائل با حداقل تاثیر؛ در درجه اول برای ثبت مسائل شناخته شده استفاده می شود. | بدون نیاز به پیدا کردن مالک یا تعمیر در یک جدول زمانی مشخص. | افشای اطلاعاتی که خطر محتمل را ایجاد نمی کند، اما در مواردی که اطلاعات نیازی به دسترسی خارجی نداشته باشد. |
اشکالات نظافت
ما در اینجا در مورد کوتاه کردن مو صحبت نمی کنیم، بلکه در مورد اطمینان از فرمت صحیح اشکالات صحبت می کنیم تا بتوان آنها را به راحتی برطرف کرد. با استفاده از جدول قبلی به عنوان راهنما، تعاریف شدت خود را تعیین کنید. این تعاریف برای طبقه بندی اشکالات به شدت های مختلف و انتقال آنها به صاحبان استفاده می شود.
علاوه بر تعیین شدت هر آسیب‌پذیری، باید مطمئن شوید اشکالات شما در قالب استانداردی هستند که پردازش تیم‌های دریافت‌کننده را آسان‌تر می‌کند. آسیب‌پذیری‌ها در قالب‌های مختلف (مانند نتایج اسکنر خودکار یا نوشتن دستی از بررسی‌های امنیتی) وارد فرآیندهای مدیریت آسیب‌پذیری شما می‌شوند. صرف زمان برای تبدیل هر آسیب‌پذیری به یک قالب استاندارد، شانس تیم دریافت‌کننده را افزایش می‌دهد که بتواند به سرعت موضوع را درک کرده و به آن رسیدگی کند.
این قالب یا الگو ممکن است بسته به سازمان شما و اطلاعاتی که برای کمک به مالکان برای رفع اشکالات اختصاص داده شده به آنها مناسب است متفاوت باشد، اما در اینجا یک الگوی نمونه وجود دارد که می توانید از آن استفاده کنید. بعداً وقتی فرم ارسال برنامه افشای آسیب‌پذیری خود را برای محققان ایجاد کردید، می‌توانید از این الگو دوباره استفاده کنید.
عنوان: <توضیح یک خطی مشکل، معمولاً نوع آسیب‌پذیری و چه دارایی/خدمات/غیره. تحت تاثیر قرار گرفته است؛ به صورت اختیاری شدت را درج کنید، یا شدت آن را به یک فیلد در ردیاب مشکل خود ترسیم کنید> خلاصه: <توضیح مختصر آسیب پذیری و چرایی اهمیت آن> مراحل بازتولید: <دستورالعمل های گام به گام در مورد نحوه نشان دادن وجود آسیب پذیری> تأثیر / سناریوی حمله: <چگونه از این مورد سوء استفاده می شود و چه تأثیری بر سازمان شما خواهد داشت؟> مراحل اصلاح: <چگونه می توان این آسیب پذیری را مستقیماً برطرف کرد، یا هر توصیه دیگری برای کمک به حداقل کاهش خطرات مرتبط با این مشکل>در اینجا یک مثال از آسیب پذیری با شدت بالا بالقوه است:
عنوان: [HIGH] مرجع ناامن مستقیم شی (IDOR) در صفحات نمایه خلاصه: یک IDOR در عملکرد صفحات نمایه برنامه ما کشف شد که به هر کاربری اجازه می‌دهد تا دسترسی غیرمجاز برای مشاهده و ویرایش نمایه کاربر دیگر، از جمله نام کامل کاربر دیگر، داشته باشد. ، آدرس منزل، شماره تلفن و تاریخ تولد. ما گزارش‌ها را بررسی کرده‌ایم و به نظر می‌رسد هنوز از این موضوع سوء استفاده نشده است. این موضوع در داخل کشف شد. مراحل تکثیر:
- یک پروکسی به عنوان مثال Burp Suite) برای رهگیری ترافیک در دستگاه تلفن همراه با نصب برنامه تنظیم کنید.
- از صفحه نمایه خود دیدن کنید و درخواست HTTP مرتبط را رهگیری کنید.
- profileID=###### را به profileID=000000 تغییر دهید (این کاربر آزمایشی است) و درخواست HTTP را ارسال کنید.
- این برنامه مشخصات کاربر 000000 را نشان می دهد و شما می توانید اطلاعات آنها را مشاهده و ویرایش کنید.
سناریوی حمله / تاثیر: هر کاربری می تواند از این آسیب پذیری برای مشاهده و ویرایش نمایه کاربر دیگر استفاده کند. در بدترین حالت، یک مهاجم می‌تواند فرآیند بازیابی اطلاعات نمایه هر کاربر را در کل سیستم ما خودکار کند. در حالی که ما معتقدیم هنوز از این مورد سوء استفاده نشده است، مهم است که این موضوع را به عنوان یک مسئله استاندارد با شدت بالا در نظر بگیریم. اگر شواهدی از استثمار مشاهده کنیم، این می تواند به شدت بحرانی افزایش یابد. مراحل اصلاح: بررسی‌های سمت سرور را اجرا کنید تا مطمئن شوید کاربر درخواست‌کننده باید به مشاهده/ویرایش نمایه درخواستی از طریق مقدار profileID دسترسی داشته باشد. به عنوان مثال، اگر آلیس وارد شده باشد و شناسه پروفایل 123456 داشته باشد، اما مشاهده شود که آلیس شناسه پروفایل 333444 را درخواست کرده است، کاربر باید خطایی ببیند و این تلاش برای دسترسی به نمایه کاربر دیگر باید ثبت شود. برای اطلاعات بیشتر در مورد IDOR و نحوه رفع آن، لطفاً به مطالب OWASP در مورد این اشکال مراجعه کنید.
می‌توانید با یافتن راه‌هایی برای تبدیل خودکار آسیب‌پذیری‌ها از منابع مختلف به قالب استاندارد خود، در زمان و تلاش دستی صرفه‌جویی کنید. همانطور که آسیب‌پذیری‌های بیشتری ایجاد می‌کنید، ممکن است مضامین مشترکی را در مراحل اصلاح پیدا کنید. فراتر از قالب فرمت اشکال عمومی خود، ممکن است بخواهید الگوهای اضافی برای انواع آسیب پذیری رایج ایجاد کنید.
پیدا کردن صاحبان
شاید یکی از سخت‌ترین جنبه‌های مدیریت آسیب‌پذیری، شناسایی مالکان برای کمک به رفع اشکال‌ها و همچنین جذب سرمایه‌شان برای تخصیص منابع برای رفع اشکال‌ها بر اساس برنامه باشد. اگر فرآیندهای مدیریت دارایی را تنظیم کرده باشید، این کار کمی آسان تر خواهد بود. اگر نه، این ممکن است به عنوان انگیزه ای برای انجام این کار باشد. بسته به اندازه سازمان شما، پیدا کردن مالک ممکن است نسبتاً ساده یا بسیار پیچیده باشد. همانطور که سازمان شما رشد می کند، تلاش برای تعیین اینکه چه کسی مسئول رفع مشکلات امنیتی تازه کشف شده است نیز افزایش می یابد. اجرای یک چرخش عملیاتی در حین انجام وظیفه را در نظر بگیرید. هر کسی که در حال انجام وظیفه است مسئول بررسی آسیب پذیری های تعیین نشده، ردیابی مالکان و اولویت بندی بر اساس شدت است. حتی اگر بتوانید تشخیص دهید که چه کسی مسئول رفع یک آسیب‌پذیری است و آنها را به باگ اختصاص دهید، باید آنها را متقاعد کنید که برای رفع آن واقعاً وقت بگذارند. این رویکرد ممکن است بر اساس تیم یا فرد و موارد دیگری که روی آنها کار می کنند متفاوت باشد. اگر به خرید سازمانی در مورد استانداردهای شدت و جدول‌های زمانی اصلاح دست یافته‌اید، می‌توانید به آنها مراجعه کنید، اما گاهی اوقات ممکن است ترغیب بیشتری لازم باشد تا کسی را وادار به رفع یک اشکال کنید. در اینجا چند نکته کلی برای اصلاح آسیب‌پذیری‌ها وجود دارد:
- توضیح دهد که چرا : زمانی که به شخصی برای رفع آسیب‌پذیری اختصاص داده می‌شود، معمولاً کار غیرمنتظره‌ای است. توضیح دهید که چرا این مشکل برای رفع به موقع اهمیت دارد (مثلاً سناریوی ضربه / حمله) و اطمینان حاصل کنید که مالک متوجه شده است.
- زمینه را جمع آوری کنید : در برخی موارد، فقط یک نفر دانش لازم برای رفع اشکال را دارد و ممکن است کارهای دیگری داشته باشد که روی آنها کار می کنند. برای یافتن این موارد وقت بگذارید - این امکان وجود دارد که سایر وظایف در کوتاه مدت مهمتر از رفع این آسیب پذیری باشند. نشان دادن همدلی و انعطاف پذیری در جدول های زمانی اصلاح به کسب حسن نیت و تقویت رابطه شما با کسانی که برای رفع آسیب پذیری ها نیاز دارید کمک می کند. فقط مراقب باشید که بیش از حد آزادی عمل ندهید، در غیر این صورت سازمان شما جدول زمانی اصلاح شما را جدی نخواهد گرفت.
- توضیح دهید که چگونه: حتی اگر توصیه‌های اصلاحی را در اشکال وارد کنید، ممکن است صاحب رفع مشکل گیج شود یا برای یادگیری نحوه رفع اشکال به کمک نیاز داشته باشد. اگر آنها به کمک نیاز دارند تا بفهمند چگونه آن را برطرف کنند، به آنها کمک کنید تا به آنها آموزش دهید. پرتاب اشکالات ساده به صاحبان بدون کمک به آنها به رابطه سازمان با تیم امنیتی آسیب می رساند. کمک به دیگران تا حد امکان به آنها قدرت می‌دهد تا آسیب‌پذیری‌های حال و آینده را برطرف کنند و همچنین به آموزش دیگران کمک کنند.
- درخواست خود را تطبیق دهید : تیم ها و افراد مختلف ممکن است فرآیندهای موجود برای نحوه پذیرش و اولویت بندی درخواست های کاری ورودی داشته باشند. برخی از تیم ها ممکن است بخواهند تمام درخواست های دریافتی از طریق مدیران آنها ارائه شود. دیگران می خواهند درخواست کمک در قالب استاندارد ارسال شود. برخی فقط روی مواردی که در یک سرعت از پیش تعریف شده است کار می کنند. در هر صورت، صرف زمان اضافی برای انطباق درخواست خود با قالبی که تیم یا فرد معمولاً برای دریافت درخواست های کمک استفاده می کند، احتمال اولویت بندی و انجام درخواست شما را افزایش می دهد.
- تشدید به عنوان آخرین راه حل : اگر همه موارد بالا را امتحان کرده اید، و فرد یا تیمی که مسئول رفع آسیب پذیری است، صرفاً برای رفع یک مشکل امنیتی جدی وقت نمی گذارد، در صورت نیاز، ارتقاء سطح رهبری را در نظر بگیرید. این همیشه باید آخرین راه حل باشد، زیرا می تواند به رابطه شما با فرد یا تیم مورد نظر آسیب برساند.
بررسی دلیل ریشه ای
علاوه بر یافتن و رفع آسیب‌پذیری‌های فردی، انجام تجزیه و تحلیل علت ریشه (RCA) می‌تواند به شما در شناسایی و رفع مشکلات امنیتی سیستمی کمک کند. همه منابع محدودی دارند، بنابراین وسوسه انگیز است که از این مرحله بگذرید. با این حال، صرف زمان برای تجزیه و تحلیل روندها در داده‌های آسیب‌پذیری شما، و همچنین بررسی بیشتر باگ‌های مهم و با شدت بالا، می‌تواند باعث صرفه‌جویی در زمان و کاهش ریسک در دراز مدت شود. به عنوان مثال، فرض کنید متوجه می‌شوید که همان نوع آسیب‌پذیری (به عنوان مثال، تغییر مسیر قصد ) بارها و بارها در سراسر برنامه شما ظاهر می‌شود. شما تصمیم می‌گیرید با تیم‌هایی که این آسیب‌پذیری را در برنامه شما معرفی می‌کنند صحبت کنید و متوجه می‌شوید که اکثریت بزرگ آنها نمی‌دانند تغییر مسیر چیست، چرا اهمیت دارد یا چگونه از آن جلوگیری کنند. شما یک سخنرانی و یک راهنما برای کمک به آموزش توسعه دهندگان در سازمان خود در مورد این آسیب پذیری جمع آوری کرده اید. این آسیب‌پذیری احتمالاً به طور کامل از بین نخواهد رفت، اما سرعت ظاهر شدن آن احتمالاً کاهش خواهد یافت. وقتی VDP خود را راه‌اندازی می‌کنید، هر آسیب‌پذیری که توسط شخص ثالث به شما گزارش می‌شود، چیزی است که در فرآیندهای امنیتی داخلی موجود شما رخنه کرده است. انجام RCA بر روی اشکالات VDP شما بینش بیشتری را در مورد چگونگی بهبود سیستماتیک برنامه امنیتی خود ارائه می دهد.
تشخیص و پاسخ
شناسایی و پاسخ به هر ابزار و فرآیندی اشاره دارد که شما برای شناسایی و پاسخ به حملات احتمالی علیه سازمان خود دارید. این می تواند به صورت راه حل های خریداری شده یا خود توسعه یافته باشد که داده ها را برای شناسایی رفتارهای مشکوک تجزیه و تحلیل می کند. به عنوان مثال، در بخش Grooming Bugs در مورد ورود هر بار که یک کاربر تلاش می کند به نمایه کاربر دیگر دسترسی غیرمجاز داشته باشد، صحبت کردیم. اگر متوجه شدید که کاربر در مدت زمان کوتاهی تعداد زیادی تلاش ناموفق برای دسترسی به نمایه های کاربران دیگر ایجاد می کند، ممکن است سیگنال یا هشداری تولید شود. حتی ممکن است فرآیند مسدود کردن آن کاربر از دسترسی به هر یک از خدمات خود را برای مدت معینی یا به طور نامحدود تا زمانی که وضعیت قابل بررسی و بازیابی دستی دسترسی باشد، خودکار کنید. اگر قبلاً مکانیسم‌های تشخیص و پاسخ را ندارید، همکاری با یک مشاور متخصص را در نظر بگیرید تا به شما کمک کند چگونه یک برنامه پزشکی قانونی دیجیتال و پاسخ به حادثه (DFIR) برای سازمان خود بسازید. اگر مکانیسم‌های تشخیص و پاسخ را از قبل در اختیار دارید، باید عواقب آزمایش پنج، ده یا حتی صد محقق امنیتی را در برابر سطوح حمله اینترنتی شما در نظر بگیرید. این می تواند تأثیر زیادی بر روی هر IDS/IPS (سیستم های تشخیص نفوذ و پیشگیری) که دارید داشته باشد.
خطرات بالقوه عبارتند از:
- بارگذاری بیش از حد هشدارها: سیل هشدارها یا سیگنال‌هایی که شبیه حملات مخرب هستند، اما در واقع عادی هستند، آزمایش‌های تایید شده توسط محققان امنیتی شرکت‌کننده در VDP شما. سر و صدای زیادی می تواند ایجاد شود که تشخیص حملات واقعی از تست امنیتی قانونی دشوار می شود.
- هشدارهای نادرست پاسخ حادثه: اگر در ساعت 2:00 بامداد روز شنبه فرآیندهایی در آن افراد صفحه وجود داشته باشد، آنها از بیدار شدن و بررسی یک نقض احتمالی که در واقع فقط یک محقق امنیتی در حال انجام آزمایش قانونی بوده، خوشحال نخواهند شد.
- مسدود کردن محققان امنیتی: اگر IPS (سیستم‌های پیشگیری از نفوذ) تهاجمی دارید، ممکن است در نهایت آدرس IP یک محقق امنیتی را مسدود کنید که سعی دارد اسکن‌ها، آزمایش‌های دستی و غیره را برای شناسایی آسیب‌پذیری‌ها و گزارش آنها به شما انجام دهد. به خصوص در مورد VDP، اگر یک محقق امنیتی پس از پنج دقیقه آزمایش مسدود شود، ممکن است علاقه خود را از دست بدهد و در عوض بر برنامه سازمان دیگری تمرکز کند. این می تواند منجر به عدم مشارکت کلی محققان امنیتی در برنامه شما شود که خطر ناشناخته ماندن آسیب پذیری ها (و در نتیجه برای سازمان شما ناشناخته) را افزایش می دهد. اگرچه ممکن است نخواهید خود IPS خود را کاهش دهید، اقدامات دیگری وجود دارد که می توانید برای کاهش خطر عدم مشارکت محققان انجام دهید.
نحوه رسیدگی به این خطرات تا حد زیادی بستگی به رویکردی دارد که می خواهید برای کار با محققان امنیتی خارجی در پیش بگیرید. اگر می‌خواهید یک روش تست جعبه سیاه بیشتری داشته باشید که حملات واقعی را شبیه‌سازی کند، ممکن است کاری انجام ندهید. در این مورد، ترافیک محقق هشدارهایی را ایجاد می کند و تیم شما ممکن است اقداماتی را برای بررسی و پاسخ مناسب انجام دهد. این به تیم شما کمک می کند تا در واکنش به حملات واقعی تمرین کند، اما ممکن است تعامل با محققان امنیتی را کاهش دهد، به خصوص اگر آنها از آزمایش مسدود شده باشند. همچنین ممکن است منجر به از دست دادن یک حمله واقعی در حین صرف زمان برای بررسی آزمایش قانونی شود. اگر بیشتر از یک رویکرد جعبه خاکستری می خواهید، می توانید با محققان امنیتی همکاری کنید تا ترافیک آزمایشی آنها را به نحوی شناسایی کنید. این به شما امکان می‌دهد تا ترافیک را از آزمایش و هشدارهای حاصل از آنها در لیست سفید قرار دهید یا در غیر این صورت فیلتر کنید. تیم شما می‌تواند حملات واقعی را از آزمایش‌های تایید شده بهتر تشخیص دهد و محققان این اختیار را خواهند داشت که آسیب‌پذیری‌ها را بیابند و به شما گزارش دهند بدون اینکه سیستم‌های پیشگیری از نفوذ شما مانع شوند. برخی از سازمان‌ها از محققان امنیتی می‌خواهند که فرمی را برای درخواست شناسه منحصربه‌فرد ارسال کنند که می‌تواند به هدرها در درخواست‌های ایجاد شده توسط محقق متصل شود. این سازمان را قادر می‌سازد تا ترافیک را برای محقق در لیست سفید قرار دهد و همچنین توانایی تشخیص اینکه آیا محقق فراتر از محدوده مورد توافق آزمایش می‌رود یا خیر. اگر این اتفاق افتاد، می توانید با محقق تماس بگیرید و از آنها بخواهید تا زمانی که بتوانید روی یک طرح آزمایشی با هم کار کنید، دست نگه دارند.