Vulnerability Disclosure Policy چیست؟ چگونه سیاست گزارش آسیب‌پذیری برای سایت ایجاد کنیم؟

Vulnerability Disclosure Policy یا VDP، سیاستی رسمی برای دریافت، بررسی و مدیریت گزارش‌های آسیب‌پذیری امنیتی سایت است. این سیاست مشخص می‌کند پژوهشگران امنیتی چگونه مشکلات را گزارش دهند، چه آزمایش‌هایی مجاز هستند، چه اطلاعاتی باید ارائه کنند و مدیر سایت چگونه گزارش‌ها را بررسی و اصلاح کند. تدوین یک سیاست گزارش آسیب‌پذیری شفاف، همکاری امن با پژوهشگران را تسهیل کرده و احتمال باقی‌ماندن مشکلات امنیتی ناشناخته را کاهش می‌دهد.

مقدمه: اگر کسی آسیب‌پذیری سایت شما را پیدا کند، چه اتفاقی می‌افتد؟

فرض کنید یک پژوهشگر امنیتی هنگام بررسی یک وب‌سایت متوجه می‌شود که بخشی از اطلاعات کاربران به دلیل یک اشتباه در کنترل دسترسی ممکن است برای افراد غیرمجاز قابل مشاهده باشد.

پژوهشگر قصد سوءاستفاده ندارد و می‌خواهد مشکل را به مالک سایت گزارش کند. اما هنگام جست‌وجو متوجه می‌شود که هیچ نشانی مشخصی برای گزارش مسائل امنیتی وجود ندارد.

فرم تماس سایت فقط برای درخواست‌های عمومی طراحی شده است. ایمیل پشتیبانی نیز مشخص نمی‌کند چه کسی مسئول دریافت گزارش‌های امنیتی است. حتی معلوم نیست بررسی محدود امنیتی توسط افراد خارج از سازمان مجاز است یا خیر.

پژوهشگر در چنین شرایطی با چند سؤال مهم مواجه می‌شود.

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

نبود پاسخ روشن برای این پرسش‌ها می‌تواند فرآیند افشای مسئولانه آسیب‌پذیری را مختل کند.

از طرف دیگر، مدیر سایت نیز ممکن است نداند چگونه گزارش دریافتی را ارزیابی کند. شاید اطلاعات را به توسعه‌دهنده اشتباه ارسال کند، شدت خطر را کمتر از واقعیت در نظر بگیرد یا بدون بررسی کافی، گزارش را نادیده بگیرد.

نتیجه این وضعیت می‌تواند باقی‌ماندن یک آسیب‌پذیری واقعی در محیط عملیاتی باشد.

سیاست گزارش آسیب‌پذیری یا Vulnerability Disclosure Policy برای مدیریت چنین شرایطی طراحی می‌شود.

این سیاست یک چارچوب مشخص برای همکاری میان مالک سامانه و افرادی ایجاد می‌کند که مشکلات امنیتی را شناسایی و به‌صورت مسئولانه گزارش می‌دهند.

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

یک فروشگاه ووکامرسی، سایت وردپرسی، سامانه آموزشی، پلتفرم مالی، نرم‌افزار SaaS یا وب‌سایت سازمانی نیز می‌تواند از چنین سیاستی استفاده کند.

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

در این مقاله از رخنه‌کاو، مفهوم Vulnerability Disclosure Policy، تفاوت آن با Bug Bounty، اجزای یک سیاست حرفه‌ای، روش تدوین و انتشار VDP، استاندارد security.txt و فرآیند عملی مدیریت گزارش‌های امنیتی را بررسی می‌کنیم.

همچنین یک نمونه سیاست گزارش آسیب‌پذیری ارائه می‌شود که می‌توان آن را متناسب با نیاز هر وب‌سایت شخصی‌سازی کرد.

Vulnerability Disclosure Policy چیست؟

Vulnerability Disclosure Policy که به اختصار VDP نامیده می‌شود، مجموعه‌ای از قواعد، تعهدات و راهنماهای رسمی است که یک سازمان برای دریافت و مدیریت گزارش‌های آسیب‌پذیری امنیتی منتشر می‌کند.

این سیاست معمولاً به‌صورت صفحه‌ای عمومی در وب‌سایت سازمان قرار می‌گیرد تا پژوهشگران امنیتی بتوانند پیش از ارسال گزارش، شرایط همکاری را مطالعه کنند.

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

برای مثال، ممکن است یک پژوهشگر متوجه شود که وب‌سایتی در اعتبارسنجی درخواست‌های کاربران ضعف دارد.

اگر سایت دارای VDP باشد، پژوهشگر می‌تواند از طریق کانال اعلام‌شده، اطلاعات لازم را برای بررسی مشکل ارسال کند.

تیم امنیت نیز براساس فرآیند از پیش تعیین‌شده، گزارش را ثبت کرده، اعتبار آن را بررسی می‌کند و در صورت تأیید، اقدامات اصلاحی را آغاز خواهد کرد.

هدف اصلی سیاست گزارش آسیب‌پذیری

هدف VDP صرفاً دریافت پیام‌های مربوط به مشکلات امنیتی نیست.

یک سیاست مناسب باید به چند پرسش اساسی پاسخ دهد:

• چه سامانه‌هایی تحت پوشش سیاست هستند؟
• چه نوع بررسی‌های امنیتی مجاز محسوب می‌شوند؟
• چه فعالیت‌هایی ممنوع هستند؟
• پژوهشگر چگونه می‌تواند گزارش ارسال کند؟
• سازمان در چه بازه‌ای دریافت گزارش را تأیید می‌کند؟
• آسیب‌پذیری چگونه بررسی و اولویت‌بندی می‌شود؟
• اطلاعات حساس گزارش چگونه محافظت می‌شوند؟
• چه زمانی و با چه شرایطی جزئیات آسیب‌پذیری منتشر خواهند شد؟
• سازمان چه رویکردی نسبت به پژوهشگران دارای حسن نیت دارد؟

پاسخ روشن به این موارد باعث کاهش ابهام و افزایش اعتماد میان طرفین می‌شود.

آیا داشتن VDP به معنای اجازه هک سایت است؟

خیر.

انتشار Vulnerability Disclosure Policy به معنای صدور مجوز نامحدود برای آزمایش امنیتی نیست.

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

برای مثال، ممکن است سازمان بررسی محدود مشکلات کنترل دسترسی در حساب آزمایشی متعلق به پژوهشگر را مجاز بداند، اما آزمایش فشار، اختلال در سرویس، استخراج داده‌های کاربران یا دسترسی به حساب دیگران را ممنوع اعلام کند.

همچنین شرایط حقوقی و محدودیت‌های قانونی باید رعایت شوند.

بنابراین، VDP نه جایگزین مجوز رسمی تست نفوذ است و نه اجازه‌ای عمومی برای اجرای هر نوع آزمایش امنیتی.

چرا سایت‌ها به سیاست گزارش آسیب‌پذیری نیاز دارند؟

امنیت وب‌سایت یک فرآیند مستمر است و هیچ ارزیابی امنیتی نمی‌تواند نبود تمام آسیب‌پذیری‌ها را تضمین کند.

حتی سازمان‌هایی که از تیم امنیت داخلی، تست نفوذ دوره‌ای و ابزارهای پیشرفته استفاده می‌کنند، ممکن است با مشکلات ناشناخته مواجه شوند.

پژوهشگران مستقل گاهی آسیب‌پذیری‌هایی را کشف می‌کنند که در بررسی‌های داخلی شناسایی نشده‌اند.

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

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

زمانی که پژوهشگر مسیر ارتباطی قابل اعتمادی پیدا نکند، ممکن است نتواند اطلاعات را به مسئول مناسب منتقل کند.

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

یک VDP شفاف می‌تواند فرآیند هماهنگی را تسهیل کند و فرصت مناسبی برای بررسی و اصلاح آسیب‌پذیری فراهم سازد.

البته وجود سیاست به‌تنهایی مانع انتشار عمومی اطلاعات نمی‌شود و سازمان باید ارتباط حرفه‌ای و پاسخ‌گویی واقعی داشته باشد.

افزایش سرعت واکنش امنیتی

گزارش‌های امنیتی اگر در میان درخواست‌های عمومی پشتیبانی باقی بمانند، ممکن است با تأخیر بررسی شوند.

تعریف یک کانال اختصاصی و مسئول مشخص می‌تواند زمان انتقال گزارش به تیم فنی را کاهش دهد.

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

ایجاد شفافیت برای پژوهشگران

پژوهشگر باید بداند چه انتظاری از رفتار او وجود دارد.

وقتی محدوده مجاز، روش گزارش‌دهی و شرایط افشای عمومی مشخص باشند، احتمال سوءتفاهم کاهش پیدا می‌کند.

این شفافیت به همکاری مسئولانه کمک می‌کند.

کمک به مدیریت ریسک سازمانی

گزارش‌های آسیب‌پذیری می‌توانند نشان دهند کدام بخش‌های یک سامانه بیشتر در معرض خطا هستند.

برای مثال، اگر در بازه‌ای چند مشکل کنترل دسترسی در یک API گزارش شود، سازمان باید علاوه بر اصلاح موارد مستقل، فرآیند توسعه و بازبینی امنیت آن API را بررسی کند.

بنابراین، اطلاعات حاصل از VDP می‌توانند به بهبود چرخه توسعه امن نرم‌افزار یا Secure Software Development Lifecycle کمک کنند.

تفاوت Vulnerability Disclosure Policy با Bug Bounty چیست؟

یکی از رایج‌ترین اشتباهات، یکسان‌دانستن سیاست گزارش آسیب‌پذیری و برنامه باگ بانتی است.

هر دو مفهوم در مدیریت آسیب‌پذیری کاربرد دارند، اما اهداف و تعهدات آن‌ها متفاوت است.

Vulnerability Disclosure Policy

VDP چارچوبی برای گزارش و مدیریت مشکلات امنیتی فراهم می‌کند.

این سیاست الزاماً شامل پرداخت پاداش مالی نیست.

ممکن است سازمان تنها دریافت گزارش را تأیید کند، نتیجه بررسی را به پژوهشگر اطلاع دهد و در صورت توافق، نام او را در فهرست قدردانی منتشر کند.

Bug Bounty Program

Bug Bounty برنامه‌ای است که در آن سازمان برای کشف و گزارش آسیب‌پذیری‌های واجد شرایط، پاداش تعیین می‌کند.

این پاداش می‌تواند مالی یا غیرمالی باشد.

در چنین برنامه‌ای معمولاً محدوده آزمایش، شرایط پذیرش گزارش، شدت آسیب‌پذیری و قواعد پرداخت پاداش مشخص می‌شوند.

مقایسه VDP و Bug Bounty

آیا بدون Bug Bounty می‌توان VDP داشت؟

بله.

یک سایت کوچک وردپرسی می‌تواند بدون پرداخت هیچ پاداشی، یک سیاست گزارش آسیب‌پذیری منتشر کند.

در این حالت، مدیر سایت باید محدوده فعالیت مجاز، روش گزارش، فرآیند پاسخ‌گویی و شرایط افشای اطلاعات را مشخص کند.

برای بسیاری از وب‌سایت‌ها، تدوین یک VDP ساده و قابل اجرا، نقطه شروع مناسب‌تری نسبت به راه‌اندازی برنامه پاداش گسترده است.

تفاوت VDP با CVD و مدیریت داخلی آسیب‌پذیری

علاوه بر VDP و Bug Bounty، دو مفهوم دیگر نیز در این حوزه اهمیت دارند.

افشای هماهنگ آسیب‌پذیری یا CVD

Coordinated Vulnerability Disclosure یا CVD فرآیندی است که در آن پژوهشگر، مالک سامانه و گاهی سایر ذی‌نفعان برای بررسی، اصلاح و انتشار اطلاعات آسیب‌پذیری هماهنگ می‌شوند.

برای مثال، اگر یک آسیب‌پذیری در افزونه‌ای عمومی شناسایی شود، ممکن است توسعه‌دهنده افزونه، کاربران محصول و یک نهاد هماهنگ‌کننده در فرآیند افشا مشارکت داشته باشند.

هدف CVD کاهش خطر برای کاربران و فراهم‌کردن فرصت مناسب برای اقدامات اصلاحی است.

مدیریت آسیب‌پذیری یا Vulnerability Management

مدیریت آسیب‌پذیری فرآیندی گسترده‌تر است که شناسایی، ارزیابی، اولویت‌بندی، اصلاح و پایش ضعف‌های امنیتی را شامل می‌شود.

گزارش‌های دریافت‌شده از طریق VDP یکی از ورودی‌های این فرآیند هستند.

در نتیجه، می‌توان گفت:

VDP مشخص می‌کند آسیب‌پذیری چگونه گزارش شود.

CVD نحوه هماهنگی میان طرف‌های مرتبط برای افشای مسئولانه را مدیریت می‌کند.

Vulnerability Management نیز چرخه گسترده شناسایی و کاهش ریسک آسیب‌پذیری‌ها را پوشش می‌دهد.

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

اجزای اصلی یک Vulnerability Disclosure Policy حرفه‌ای

یک سیاست گزارش آسیب‌پذیری باید به‌اندازه کافی شفاف باشد تا پژوهشگر بداند چه اقداماتی مجاز هستند و تیم داخلی نیز بتواند گزارش‌ها را به‌صورت یکسان مدیریت کند.

۱. معرفی هدف و تعهد سازمان

در ابتدای سیاست، بهتر است سازمان توضیح دهد چرا از گزارش‌های امنیتی استقبال می‌کند.

برای مثال، می‌توان بیان کرد که حفاظت از اطلاعات کاربران اهمیت دارد و گزارش‌های مسئولانه به شناسایی مشکلات احتمالی کمک می‌کنند.

این بخش باید حرفه‌ای و واقع‌بینانه باشد.

ادعاهایی مانند تضمین امنیت کامل یا جلوگیری قطعی از تمام حملات نباید مطرح شوند.

۲. تعیین محدوده مجاز یا Scope

Scope یکی از مهم‌ترین قسمت‌های VDP است.

این بخش مشخص می‌کند کدام دامنه‌ها، زیر دامنه‌ها، برنامه‌ها یا APIها تحت پوشش سیاست قرار دارند.

برای مثال، ممکن است سازمان صرفاً دامنه اصلی و یک زیر دامنه آزمایشی را در محدوده مجاز قرار دهد.

نباید فرض کرد تمام دارایی‌هایی که نام برند سازمان را دارند، به‌صورت خودکار مجاز هستند.

۳. معرفی فعالیت‌های ممنوع

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

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

۴. روش ارسال گزارش

حداقل یک روش ارتباطی معتبر باید معرفی شود.

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

۵. تعهدات پاسخ‌گویی

سازمان بهتر است مشخص کند در چه بازه‌ای دریافت گزارش را تأیید می‌کند و چگونه وضعیت بررسی را اطلاع می‌دهد.

زمان‌بندی باید متناسب با ظرفیت واقعی تیم باشد.

۶. چارچوب افشای اطلاعات

باید مشخص شود پژوهشگر و سازمان چگونه درباره انتشار عمومی جزئیات آسیب‌پذیری هماهنگ می‌شوند.

۷. شرایط رفتار مسئولانه

سیاست باید انتظارات سازمان از پژوهشگران دارای حسن نیت را بیان کند.

این بخش می‌تواند شامل محدودسازی آزمایش، حفاظت از داده‌ها و توقف بررسی هنگام مواجهه با اطلاعات حساس باشد.

۸. روش قدردانی

اگر سازمان قصد دارد از پژوهشگران قدردانی کند، بهتر است شرایط آن را از ابتدا مشخص سازد.

قدردانی ممکن است شامل انتشار نام پژوهشگر با رضایت او باشد.

نباید بدون برنامه مشخص، وعده پاداش مالی داده شود.

چگونه محدوده مجاز تست امنیتی را در VDP مشخص کنیم؟

تعریف محدوده دقیق یکی از اقدامات اساسی در تدوین سیاست گزارش آسیب‌پذیری است.

یک محدوده مبهم می‌تواند باعث شود پژوهشگران تصور کنند هر سرویس مرتبط با نام سازمان برای بررسی مجاز است.

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

ابتدا باید فهرستی از دارایی‌های دیجیتال تهیه شود.

این فهرست می‌تواند شامل وب‌سایت اصلی، برنامه‌های اختصاصی، APIها و محیط‌های آزمایشی باشد.

برای هر دارایی باید مالک فنی و وضعیت مجوز بررسی امنیتی مشخص شود.

بهتر است دارایی‌ها با نشانی دقیق یا شناسه مشخص معرفی شوند.

دارایی‌های خارج از محدوده

سامانه‌هایی که توسط اشخاص ثالث مدیریت می‌شوند، لزوماً تحت مجوز سازمان نیستند.

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

همچنین سرویس‌های ایمیل، سامانه‌های پشتیبانی و خدمات ابری مستقل باید براساس شرایط مالکیت و مجوز بررسی شوند.

وضعیت زیر دامنه‌ها

اگر سازمان قصد دارد تمام زیر دامنه‌های یک دامنه را تحت پوشش قرار دهد، باید این تصمیم را صریح اعلام کند.

استفاده از عبارت‌هایی مانند تمام سرویس‌های مرتبط با شرکت، بدون تعیین دقیق دامنه اختیار، مناسب نیست.

برای سایت‌هایی که از چند ارائه‌دهنده زیرساخت استفاده می‌کنند، بررسی حقوق قراردادی نیز اهمیت دارد.

محیط آزمایشی یا Staging

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

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

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

چه آزمایش‌هایی در سیاست گزارش آسیب‌پذیری مجاز باشند؟

یک VDP حرفه‌ای باید فعالیت‌های قابل قبول و غیرقابل قبول را از یکدیگر تفکیک کند.

مجازبودن یک آزمایش به معنای نبود محدودیت نیست.

بررسی‌های کم‌خطر

سازمان می‌تواند بررسی‌های محدود و غیرمخرب را در دارایی‌های اعلام‌شده مجاز بداند.

برای مثال، بررسی یک رفتار امنیتی مشکوک در حساب آزمایشی متعلق به پژوهشگر، در صورت انطباق با شرایط سیاست، ممکن است قابل قبول باشد.

همچنین گزارش مشکلات پیکربندی آشکار یا ضعف‌های امنیتی قابل مشاهده بدون دسترسی غیرمجاز می‌تواند مفید باشد.

آزمایش‌های مربوط به حساب‌های آزمایشی

اگر سازمان اجازه ایجاد حساب آزمایشی می‌دهد، باید مشخص کند چه شرایطی برای استفاده از آن وجود دارد.

پژوهشگر نباید به داده‌ها، نشست‌ها یا حساب‌های دیگران دسترسی پیدا کند.

در صورت مواجهه اتفاقی با اطلاعات کاربران، آزمایش باید متوقف شود و موضوع از طریق کانال امن گزارش شود.

اثبات محدود وجود آسیب‌پذیری

گاهی پژوهشگر برای اثبات وجود مشکل نیازمند انجام یک بررسی محدود است.

سیاست باید روشن کند که اثبات آسیب‌پذیری باید با کمترین میزان تعامل و بدون استخراج داده واقعی انجام شود.

برای مثال، در بررسی یک ضعف کنترل دسترسی، استفاده از حساب‌های آزمایشی تحت کنترل پژوهشگر نسبت به تعامل با حساب‌های واقعی دیگران ایمن‌تر است.

در هر صورت، محدوده مجاز باید از قبل مشخص شده باشد.

چه فعالیت‌هایی باید در VDP ممنوع شوند؟

محدودیت‌ها باید متناسب با نوع سایت و سطح ریسک آن تعریف شوند.

برخی فعالیت‌ها معمولاً برای برنامه‌های عمومی گزارش آسیب‌پذیری مناسب نیستند.

حملات اختلال در سرویس

آزمایش‌های Denial of Service یا DoS و Distributed Denial of Service یا DDoS می‌توانند باعث اختلال در دسترس‌پذیری سامانه شوند.

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

حملات Brute Force

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

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

مهندسی اجتماعی

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

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

استخراج اطلاعات کاربران

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

اگر پژوهشگر به‌صورت تصادفی با چنین اطلاعاتی مواجه شود، باید تعامل را متوقف کند و موضوع را گزارش دهد.

تغییر یا تخریب اطلاعات

تغییر اطلاعات کاربران، حذف فایل‌ها، تغییر تنظیمات عملیاتی و اقداماتی که باعث آسیب به سامانه می‌شوند باید ممنوع باشند.

آزمایش زیرساخت اشخاص ثالث

سرویس‌هایی که خارج از مالکیت و کنترل سازمان قرار دارند، تنها با مجوز معتبر مالک مربوط قابل بررسی هستند.

Safe Harbor در سیاست گزارش آسیب‌پذیری چیست؟

Safe Harbor یکی از مفاهیم مهم در برنامه‌های افشای آسیب‌پذیری است.

این اصطلاح در زمینه VDP به موضع و تعهدات اعلام‌شده سازمان نسبت به پژوهشگران امنیتی دارای حسن نیت اشاره دارد.

هدف چنین بخشی کاهش نگرانی پژوهشگر درباره واکنش سازمان به فعالیت‌هایی است که در محدوده مجاز و مطابق سیاست انجام می‌شوند.

چرا Safe Harbor اهمیت دارد؟

اگر پژوهشگران نگران باشند که حتی گزارش مسئولانه یک مشکل به برخورد نامناسب منجر شود، ممکن است تمایل کمتری به همکاری داشته باشند.

یک بیانیه روشن می‌تواند مشخص کند سازمان نسبت به فعالیت‌های مجاز و دارای حسن نیت چه رویکردی دارد.

Safe Harbor چه چیزی را تضمین نمی‌کند؟

Safe Harbor نباید به‌عنوان مصونیت حقوقی مطلق معرفی شود.

مالک وب‌سایت نمی‌تواند از طرف تمام اشخاص ثالث، نهادهای قانونی یا ارائه‌دهندگان زیرساخت تعهد ایجاد کند.

همچنین یک سیاست عمومی نمی‌تواند فعالیت‌های غیرقانونی یا اقدامات خارج از محدوده مجاز را به‌صورت خودکار قانونی کند.

بنابراین، متن Safe Harbor باید متناسب با قوانین حوزه قضایی، قراردادهای سازمان و حدود اختیارات واقعی تنظیم شود.

چگونه متن Safe Harbor تدوین شود؟

سازمان می‌تواند اعلام کند که نسبت به پژوهش‌های دارای حسن نیت، در محدوده مجاز و مطابق شرایط منتشرشده، رویکرد حمایتی و همکاری‌محور دارد.

در ادامه باید محدودیت‌های این تعهد مشخص شوند.

برای مثال، فعالیت‌های مخرب، دسترسی غیرمجاز به اطلاعات دیگران و آزمایش سرویس‌های خارج از محدوده، نباید تحت پوشش این بخش قرار گیرند.

بازبینی حقوقی متن پیش از انتشار اهمیت زیادی دارد.

روش‌های دریافت گزارش آسیب‌پذیری

یکی از مهم‌ترین بخش‌های عملیاتی VDP، ایجاد یک مسیر ارتباطی قابل اعتماد است.

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

استفاده از ایمیل امنیتی اختصاصی

یکی از روش‌های ساده، ایجاد آدرس ایمیل اختصاصی مانند [email protected] است.

این نشانی صرفاً یک نمونه است و باید با دامنه واقعی سازمان جایگزین شود.

بهتر است صندوق ایمیل توسط افراد مسئول بررسی شود و دسترسی به آن محدود باشد.

همچنین باید برای زمان‌های غیبت مسئول اصلی، جانشین مشخصی وجود داشته باشد.

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

فرم اختصاصی می‌تواند دریافت اطلاعات را ساختاریافته کند.

برای مثال، می‌توان فیلدهایی برای نام اختیاری، روش تماس، نشانی سامانه، شرح آسیب‌پذیری، اثر امنیتی و مدارک لازم ایجاد کرد.

فرم باید از HTTPS استفاده کند و فایل‌های پیوست را به‌صورت امن مدیریت کند.

استفاده از کانال ارتباطی رمزگذاری‌شده

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

سازمان می‌تواند کلید عمومی OpenPGP معتبر ارائه کند یا از یک سامانه گزارش‌دهی امن استفاده کند.

کلید عمومی باید از مسیر قابل اعتماد در دسترس باشد.

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

استفاده از پلتفرم تخصصی

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

این پلتفرم‌ها می‌توانند امکاناتی مانند ثبت وضعیت، مدیریت مکاتبات، بررسی گزارش‌های تکراری و کنترل دسترسی را فراهم کنند.

با این حال، انتخاب پلتفرم به‌تنهایی جایگزین تعیین مسئولیت‌ها و فرآیند رسیدگی نیست.

گزارش آسیب‌پذیری باید شامل چه اطلاعاتی باشد؟

برای بررسی مؤثر یک گزارش، تیم امنیت به اطلاعات کافی نیاز دارد.

از سوی دیگر، درخواست مدارک بیش از حد می‌تواند پژوهشگر را به انجام آزمایش‌های غیرضروری تشویق کند.

بهترین رویکرد، دریافت حداقل اطلاعات لازم برای ارزیابی ایمن مشکل است.

عنوان آسیب‌پذیری

عنوان باید نوع مشکل و بخش مرتبط را به‌صورت کوتاه توصیف کند.

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

سامانه تحت تأثیر

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

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

توضیح فنی

شرح آسیب‌پذیری باید به اندازه‌ای دقیق باشد که تیم فنی بتواند رفتار گزارش‌شده را در محیط مجاز بررسی کند.

توضیح باید بر شرایط بروز، نتیجه مشاهده‌شده و اثر امنیتی تمرکز داشته باشد.

نیازی نیست پژوهشگر برای اثبات مشکل، اطلاعات خصوصی کاربران را استخراج کند.

اثر امنیتی

گزارش باید توضیح دهد آسیب‌پذیری چه خطری ایجاد می‌کند.

برای مثال، ممکن است مشکل بر محرمانگی اطلاعات، یکپارچگی داده‌ها یا دسترس‌پذیری سرویس اثر بگذارد.

مدارک محدود و ایمن

تصاویر، لاگ‌های پالایش‌شده یا اطلاعات آزمایشی می‌توانند به بررسی گزارش کمک کنند.

پژوهشگر باید داده‌های حساس، توکن‌های معتبر، رمزهای عبور و اطلاعات شخصی را از مدارک حذف کند.

اطلاعات تماس

در صورت تمایل پژوهشگر، وجود یک روش ارتباطی مناسب امکان پیگیری نتیجه بررسی را فراهم می‌کند.

سازمان باید مشخص کند آیا گزارش ناشناس را نیز می‌پذیرد یا خیر.

فرآیند مدیریت گزارش آسیب‌پذیری از دریافت تا اصلاح

داشتن صفحه VDP تنها آغاز کار است.

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

مرحله اول: دریافت و ثبت گزارش

پس از دریافت گزارش، بهتر است یک شناسه پیگیری ایجاد شود.

این شناسه به ارتباط منظم میان پژوهشگر و تیم امنیت کمک می‌کند.

اطلاعات ثبت‌شده می‌توانند شامل تاریخ دریافت، سامانه مرتبط، وضعیت فعلی و مسئول بررسی باشند.

مرحله دوم: تأیید دریافت گزارش

سازمان باید در بازه اعلام‌شده دریافت گزارش را تأیید کند.

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

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

مرحله سوم: ارزیابی اولیه یا Triage

در این مرحله مشخص می‌شود آیا گزارش مربوط به محدوده برنامه است و آیا اطلاعات کافی برای بررسی دارد.

همچنین باید بررسی شود مشکل قبلاً گزارش شده است یا خیر.

گزارش‌های خارج از محدوده می‌توانند مطابق سیاست مشخص به مسیر مناسب هدایت شوند.

مرحله چهارم: اعتبارسنجی فنی

تیم مسئول باید وجود مشکل را در محیط مجاز و ترجیحاً آزمایشی بررسی کند.

هدف، تأیید رفتار گزارش‌شده با حداقل خطر برای سرویس و کاربران است.

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

مرحله پنجم: ارزیابی شدت و اثر

پس از تأیید، شدت آسیب‌پذیری ارزیابی می‌شود.

در این مرحله، نوع داده‌های تحت تأثیر، شرایط سوءاستفاده، سطح دسترسی مورد نیاز و پیامدهای احتمالی اهمیت دارند.

ارزیابی باید براساس شرایط واقعی سامانه انجام شود.

مرحله ششم: تعیین مسئول اصلاح

گزارش باید به تیم فنی یا مالک محصول مربوط واگذار شود.

در سازمان‌های بزرگ، این مسئول می‌تواند تیم توسعه، زیرساخت، عملیات امنیت یا تأمین‌کننده نرم‌افزار باشد.

مالکیت اصلاح باید مشخص و قابل پیگیری باشد.

مرحله هفتم: طراحی و اجرای اصلاح

راهکار اصلاحی باید علت ریشه‌ای مشکل را برطرف کند.

برای مثال، اگر چند Endpoint دارای نقص کنترل دسترسی باشند، اصلاح صرف یک مسیر ممکن است کافی نباشد.

بهتر است الگوی مشترک خطا نیز بررسی شود.

مرحله هشتم: آزمون مجدد

پس از اعمال اصلاح، باید بررسی شود که مشکل واقعاً برطرف شده و تغییر ایجادشده باعث بروز آسیب‌پذیری جدید نشده است.

آزمون‌های رگرسیون امنیتی در این مرحله اهمیت دارند.

مرحله نهم: اطلاع‌رسانی و بستن گزارش

پس از تأیید اصلاح، وضعیت نهایی گزارش ثبت می‌شود.

در صورت امکان و بدون افشای جزئیات حساس، نتیجه به پژوهشگر اطلاع داده می‌شود.

اگر انتشار عمومی در برنامه قرار دارد، باید فرآیند هماهنگی مربوط انجام شود.

تعیین زمان پاسخ‌گویی و SLA در سیاست گزارش آسیب‌پذیری

یکی از پرسش‌های مهم در طراحی VDP این است که سازمان چه زمانی باید پاسخ دهد.

پاسخ واحدی برای تمام سازمان‌ها وجود ندارد.

زمان‌بندی باید براساس ظرفیت تیم، حساسیت سامانه و فرآیند عملیاتی انتخاب شود.

با این حال، تعریف زمان‌های هدف می‌تواند انتظارات را شفاف‌تر کند.

نمونه زمان‌بندی پیشنهادی

این زمان‌ها نمونه‌ای برای طراحی سیاست هستند و الزام همگانی یا تضمین استاندارد محسوب نمی‌شوند.

تفاوت زمان پاسخ و زمان اصلاح

تأیید دریافت گزارش با اصلاح آسیب‌پذیری تفاوت دارد.

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

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

اگر سازمان نتواند در زمان مقرر اصلاح کند چه می‌شود؟

در چنین شرایطی، ارتباط شفاف با پژوهشگر اهمیت دارد.

سازمان باید وضعیت بررسی و محدودیت‌های موجود را تا حدی که امنیت سامانه اجازه می‌دهد توضیح دهد.

همچنین ممکن است اجرای کنترل‌های موقت برای کاهش ریسک ضروری باشد.

تعهدات غیرواقعی و وعده‌های قطعی، اعتماد پژوهشگران را کاهش می‌دهند.

چگونه شدت آسیب‌پذیری‌های گزارش‌شده را تعیین کنیم؟

تمام گزارش‌های امنیتی اهمیت یکسان ندارند.

برخی آسیب‌پذیری‌ها ممکن است تنها اطلاعات کم‌اهمیتی را آشکار کنند، در حالی که بعضی دیگر می‌توانند بر داده‌های حساس یا عملیات حیاتی اثر بگذارند.

استفاده از CVSS

Common Vulnerability Scoring System یا CVSS یک چارچوب استاندارد برای توصیف و امتیازدهی ویژگی‌های فنی شدت آسیب‌پذیری است.

در صورت استفاده، باید نسخه چارچوب و مبنای امتیاز مشخص باشند.

CVSS می‌تواند به تحلیل فنی کمک کند، اما به‌تنهایی تمام شرایط تجاری و عملیاتی سازمان را نشان نمی‌دهد.

ارزیابی براساس ریسک واقعی

برای اولویت‌بندی اصلاح، عوامل دیگری نیز اهمیت دارند:

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

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

تعیین وضعیت گزارش

بهتر است گزارش‌ها دارای وضعیت‌های مشخص باشند.

وضعیت‌هایی مانند دریافت‌شده، در حال بررسی، تأییدشده، در حال اصلاح، اصلاح‌شده، نیازمند اطلاعات بیشتر و بسته‌شده می‌توانند مفید باشند.

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

افشای هماهنگ آسیب‌پذیری چگونه انجام می‌شود؟

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

انتشار زودهنگام جزئیات ممکن است خطر سوءاستفاده را افزایش دهد.

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

هماهنگی با پژوهشگر

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

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

این درخواست باید همراه با پاسخ‌گویی منظم و تلاش واقعی برای کاهش خطر باشد.

آیا دوره ۹۰ روزه الزامی است؟

خیر.

در برخی فرآیندهای افشای هماهنگ، بازه‌هایی مانند ۹۰ روز استفاده می‌شوند؛ اما این مدت یک الزام جهانی برای تمام آسیب‌پذیری‌ها نیست.

زمان مناسب می‌تواند براساس شدت مشکل، وجود سوءاستفاده فعال، تعداد محصولات متأثر و هماهنگی طرف‌ها متفاوت باشد.

یک سایت کوچک نباید بدون ارزیابی ظرفیت و شرایط خود، تعهد ثابت و غیرقابل تغییر ایجاد کند.

افشای زودهنگام در شرایط اضطراری

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

در این شرایط، سازمان باید انتشار هشدار یا راهنمای کاهش خطر را مطابق برنامه پاسخ به حادثه بررسی کند.

مهم است که اطلاع‌رسانی عمومی، اطلاعات لازم برای دفاع را ارائه کند و از انتشار غیرضروری جزئیات قابل سوءاستفاده خودداری شود.

هماهنگی با تأمین‌کنندگان

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

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

فایل security.txt چیست و چه ارتباطی با VDP دارد؟

فایل security.txt یک قالب متنی استاندارد برای معرفی اطلاعات لازم جهت گزارش آسیب‌پذیری‌های امنیتی است.

این فایل براساس RFC 9116 تعریف شده و به پژوهشگران کمک می‌کند راه ارتباطی و سیاست افشای آسیب‌پذیری سازمان را پیدا کنند.

در محیط وب، محل استاندارد انتشار آن مسیر زیر است:

https://example.com/.well-known/security.txt

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

security.txt تنها یک ابزار کمکی برای معرفی اطلاعات تماس و سیاست مربوط است.

فیلد Contact

Contact روش ارتباط با تیم مسئول دریافت گزارش را مشخص می‌کند.

این فیلد ضروری است.

برای مثال، می‌توان یک آدرس ایمیل امنیتی یا لینک فرم گزارش را معرفی کرد.

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

فیلد Expires

Expires زمان پایان اعتبار اطلاعات موجود در فایل را مشخص می‌کند.

این فیلد نیز ضروری است.

هدف از آن جلوگیری از اتکای پژوهشگران به اطلاعات قدیمی یا مسیرهای تماس منسوخ است.

تاریخ باید در قالب معتبر زمانی درج شود و سازمان پیش از انقضای آن، فایل را بازبینی کند.

فیلد Policy

Policy می‌تواند نشانی صفحه سیاست گزارش آسیب‌پذیری را مشخص کند.

این فیلد برای معرفی قواعد برنامه بسیار مفید است.

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

فیلد Encryption

Encryption برای معرفی اطلاعات مربوط به رمزگذاری ارتباطات امنیتی کاربرد دارد.

برای مثال، سازمان می‌تواند نشانی کلید عمومی OpenPGP خود را معرفی کند.

فیلد Canonical

Canonical محل معتبر فایل security.txt را مشخص می‌کند.

این فیلد با تگ Canonical مربوط به سئوی صفحات وب تفاوت دارد.

در security.txt، هدف کمک به تشخیص محل معتبر اطلاعات امنیتی است.

نمونه فایل security.txt

نمونه زیر صرفاً آموزشی است و نشانی‌ها و تاریخ آن باید پیش از استفاده تغییر کنند.

Contact: mailto:[email protected]
Expires: 2027-02-01T00:00:00Z
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/vulnerability-disclosure-policy/

در این نمونه، Contact و Expires فیلدهای ضروری هستند و دو فیلد دیگر اطلاعات تکمیلی ارائه می‌کنند.

نشانی‌ها باید به منابع معتبر و تحت کنترل سازمان اشاره کنند.

فایل security.txt باید با HTTPS قابل دریافت باشد.

نوع محتوای آن نیز باید مطابق مشخصات استاندارد، متن ساده با کدگذاری UTF-8 باشد.

آیا security.txt تمام زیر دامنه‌ها را پوشش می‌دهد؟

خیر، نه به‌صورت خودکار.

فایلی که روی یک دامنه منتشر شده است، به‌تنهایی برای تمام زیر دامنه‌ها یا دامنه مادر آن معتبر محسوب نمی‌شود.

برای معرفی محدوده واقعی برنامه، بهتر است سیاست منتشرشده توضیح روشنی درباره دارایی‌های تحت پوشش داشته باشد.

آیا داشتن security.txt امنیت سایت را افزایش می‌دهد؟

این فایل به‌تنهایی آسیب‌پذیری‌ها را اصلاح نمی‌کند و جایگزین کنترل‌هایی مانند WAF، مدیریت دسترسی یا به‌روزرسانی نرم‌افزار نیست.

اما می‌تواند ارتباط میان پژوهشگران و مسئولان امنیت را تسهیل کند.

در نتیجه، ارزش آن در پشتیبانی از فرآیند گزارش و مدیریت آسیب‌پذیری است.

چگونه برای سایت وردپرسی Vulnerability Disclosure Policy ایجاد کنیم؟

راه‌اندازی سیاست گزارش آسیب‌پذیری در وردپرس نیازمند توسعه یک سامانه پیچیده نیست.

برای بسیاری از سایت‌ها، یک صفحه عمومی، مسیر تماس امن و فرآیند داخلی مشخص کافی است.

مرحله اول: ارزیابی دارایی‌های سایت

ابتدا باید مشخص شود کدام بخش‌های سایت در مالکیت و کنترل شما هستند.

این بخش‌ها می‌توانند شامل هسته برنامه اختصاصی، قالب سفارشی، افزونه‌های توسعه‌یافته توسط تیم، API اختصاصی و محیط آزمایشی باشند.

اگر از افزونه‌های عمومی استفاده می‌کنید، باید تفاوت میان مسئولیت سایت و مسئولیت توسعه‌دهنده افزونه را در نظر بگیرید.

مرحله دوم: ایجاد صفحه سیاست

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

می‌توانید از نشانی انگلیسی زیر استفاده کنید:

/vulnerability-disclosure-policy/

این نشانی یک انتخاب پیشنهادی برای انتشار سیاست است.

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

مرحله سوم: تعیین اطلاعات تماس

یک ایمیل اختصاصی یا فرم امن برای گزارش مسائل امنیتی ایجاد کنید.

بهتر است اطلاعات این مسیر در اختیار افراد مسئول قرار بگیرد.

استفاده از ایمیل عمومی فروش یا تبلیغات به‌عنوان تنها کانال گزارش امنیتی توصیه نمی‌شود.

مرحله چهارم: مشخص‌کردن محدوده مجاز

در صفحه سیاست، دامنه‌ها و سرویس‌های مجاز را معرفی کنید.

اگر نمی‌خواهید سایت عملیاتی تحت آزمایش‌های گسترده قرار بگیرد، محدودیت را به‌روشنی بیان کنید.

مرحله پنجم: انتشار فایل security.txt

پس از آماده‌شدن سیاست، فایل security.txt را در مسیر استاندارد قرار دهید.

در بسیاری از ساختارهای میزبانی وردپرس، این کار از طریق مدیریت فایل یا تنظیمات سرور امکان‌پذیر است.

باید بررسی شود فایل واقعاً از مسیر مورد انتظار قابل دسترسی است.

همچنین تنظیمات سرور، CDN یا افزونه‌های امنیتی نباید مانع دریافت آن شوند.

مرحله ششم: بررسی دسترسی و تنظیمات امنیتی

فرم یا صندوق دریافت گزارش باید از دسترسی غیرمجاز محافظت شود.

اگر از افزونه فرم‌ساز استفاده می‌کنید، باید روش نگهداری اطلاعات و فایل‌های پیوست آن بررسی شود.

وجود توکن CSRF، محدودسازی ارسال درخواست و اعتبارسنجی فایل‌های آپلودشده در فرم‌های سفارشی اهمیت دارد.

همچنین گزارش‌های حساس نباید در بخش‌های عمومی یا مسیرهای قابل دسترسی بدون احراز هویت ذخیره شوند.

مرحله هفتم: تعیین مسئول رسیدگی

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

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

مرحله هشتم: آزمایش فرآیند

پس از انتشار، بهتر است یک گزارش آزمایشی غیرحساس ارسال شود.

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

همچنین باید مشخص شود تیم پشتیبانی در صورت دریافت گزارش از مسیر عمومی، چگونه آن را به مسئول امنیت منتقل می‌کند.

ملاحظات ویژه VDP برای فروشگاه‌های ووکامرسی

فروشگاه اینترنتی ممکن است اطلاعات حساب‌های کاربران، سفارش‌ها، آدرس‌ها و داده‌های تجاری را پردازش کند.

به همین دلیل، سیاست گزارش آسیب‌پذیری چنین سایتی باید با حساسیت بیشتری طراحی شود.

حفاظت از اطلاعات سفارش‌ها

اگر پژوهشگر احتمال نقص کنترل دسترسی در مشاهده سفارش‌ها را تشخیص دهد، نباید برای اثبات مشکل به اطلاعات مشتریان واقعی دسترسی پیدا کند.

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

تفکیک محدوده درگاه پرداخت

درگاه پرداخت خارجی باید به‌عنوان یک سرویس مستقل در نظر گرفته شود، مگر اینکه مالک آن مجوز مشخصی ارائه کرده باشد.

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

بررسی آسیب‌پذیری‌های افزونه‌ها

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

در چنین مواردی، تیم سایت باید خطر موجود در استقرار خود را مدیریت کند و در صورت لزوم با توسعه‌دهنده محصول هماهنگ شود.

مدیریت گزارش‌های مربوط به اطلاعات مالی

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

در این موارد، حفاظت از اطلاعات مشتریان و محدودسازی دسترسی به مدارک گزارش اهمیت ویژه‌ای دارد.

امنیت فرم گزارش آسیب‌پذیری چگونه تأمین شود؟

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

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

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

فیلدهای فرم باید از نظر طول، قالب و نوع داده اعتبارسنجی شوند.

همچنین هنگام نمایش اطلاعات ثبت‌شده، باید اصول Output Encoding رعایت شوند تا خطراتی مانند Cross-Site Scripting یا XSS کاهش پیدا کنند.

محافظت در برابر CSRF

اگر فرم دارای عملیات حساس یا مرتبط با نشست کاربر است، باید کنترل‌های مناسب در برابر Cross-Site Request Forgery اعمال شوند.

استفاده از توکن‌های معتبر و بررسی شرایط درخواست می‌تواند بخشی از این دفاع باشد.

محدودسازی آپلود فایل

اگر پژوهشگران امکان ارسال فایل دارند، باید نوع، حجم و نحوه نگهداری فایل‌ها محدود شود.

پیوست‌ها نباید بدون بررسی و محدودیت مناسب در مسیرهای عمومی قابل اجرا قرار بگیرند.

بهتر است دسترسی به فایل‌ها تنها برای افراد مسئول امکان‌پذیر باشد.

مقابله با پیام‌های انبوه

فرم عمومی ممکن است با اسپم یا درخواست‌های خودکار مواجه شود.

استفاده از Rate Limiting، محدودیت حجم درخواست و کنترل‌های ضدسوءاستفاده می‌تواند مفید باشد.

این کنترل‌ها باید به شکلی اجرا شوند که پژوهشگران واقعی بدون مانع غیرضروری امکان گزارش داشته باشند.

حفاظت از محرمانگی گزارش

گزارش‌های امنیتی گاهی شامل جزئیات ضعف‌های اصلاح‌نشده هستند.

بنابراین، ذخیره آن‌ها در محیط عمومی یا ارسال به اشخاص غیرمرتبط می‌تواند خطرناک باشد.

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

نمونه سیاست گزارش آسیب‌پذیری برای وب‌سایت

متن زیر نمونه‌ای قابل شخصی‌سازی از Vulnerability Disclosure Policy است.

این نمونه باید پیش از انتشار، متناسب با دامنه‌ها، توان عملیاتی، محدودیت‌های فنی و الزامات حقوقی سازمان اصلاح شود.

معرفی و هدف

امنیت اطلاعات کاربران و پایداری خدمات برای مجموعه ما اهمیت بالایی دارد.

ما از گزارش‌های مسئولانه پژوهشگران امنیتی درباره آسیب‌پذیری‌های احتمالی سامانه‌های تحت مالکیت خود استقبال می‌کنیم.

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

محدوده برنامه

این سیاست تنها شامل دارایی‌هایی است که به‌صورت مشخص در فهرست رسمی سامانه‌های مجاز معرفی شده‌اند.

سرویس‌های متعلق به اشخاص ثالث، زیرساخت‌های مستقل و دارایی‌های اعلام‌نشده، خارج از محدوده هستند.

هرگونه بررسی امنیتی باید در محدوده تعیین‌شده و مطابق قوانین مربوط انجام شود.

فعالیت‌های مجاز

پژوهشگران می‌توانند بررسی‌های محدود، غیرمخرب و مطابق شرایط اعلام‌شده را روی دارایی‌های مجاز انجام دهند.

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

در صورت مواجهه با داده‌های حساس یا اطلاعات دیگران، پژوهشگر باید بررسی را متوقف کرده و موضوع را گزارش کند.

فعالیت‌های ممنوع

فعالیت‌هایی که باعث اختلال در سرویس، حذف یا تغییر اطلاعات، دسترسی به حساب‌های دیگران، استخراج داده‌ها یا آسیب به زیرساخت می‌شوند، مجاز نیستند.

حملات DoS، DDoS، Brute Force، مهندسی اجتماعی و بررسی سرویس‌های خارج از محدوده نیز بدون مجوز مستقل ممنوع هستند.

روش ارسال گزارش

گزارش‌های امنیتی باید از طریق کانال رسمی اعلام‌شده ارسال شوند.

گزارش بهتر است شامل عنوان مشکل، سامانه تحت تأثیر، شرح فنی، اثر احتمالی و مدارک محدود و غیرحساس باشد.

پژوهشگران باید از ارسال رمز عبور، توکن معتبر و اطلاعات شخصی غیرضروری خودداری کنند.

پاسخ‌گویی

ما تلاش می‌کنیم دریافت گزارش را حداکثر طی سه روز کاری تأیید کنیم.

ارزیابی اولیه براساس اطلاعات موجود و ظرفیت تیم فنی انجام خواهد شد.

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

در صورت امکان، وضعیت رسیدگی از طریق روش تماس اعلام‌شده به پژوهشگر اطلاع داده می‌شود.

افشای هماهنگ

از پژوهشگران درخواست می‌کنیم پیش از انتشار عمومی جزئیات آسیب‌پذیری، با تیم مسئول هماهنگ کنند.

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

زمان انتشار اطلاعات براساس شرایط امنیتی و توافق قابل اجرا تعیین می‌شود.

رفتار دارای حسن نیت

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

رویکرد ما در قبال چنین گزارش‌هایی همکاری حرفه‌ای و تلاش برای اصلاح مشکلات امنیتی است.

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

حفظ محرمانگی

اطلاعات دریافتی تنها برای اهداف مرتبط با ارزیابی و مدیریت آسیب‌پذیری مورد استفاده قرار می‌گیرند.

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

قدردانی از پژوهشگران

در صورت تمایل پژوهشگر و با توافق طرفین، ممکن است از همکاری او به‌صورت عمومی قدردانی شود.

ارسال گزارش به‌تنهایی تعهدی برای پرداخت پاداش مالی ایجاد نمی‌کند، مگر اینکه چنین برنامه‌ای به‌صورت مستقل و رسمی اعلام شده باشد.

به‌روزرسانی سیاست

این سیاست ممکن است متناسب با تغییرات زیرساخت، فرآیندهای امنیتی و الزامات عملیاتی بازبینی شود.

نسخه منتشرشده در وب‌سایت رسمی، مبنای اطلاع‌رسانی عمومی درباره شرایط برنامه خواهد بود.

سناریوهای واقعی‌نما برای درک کاربرد VDP

برای شناخت بهتر ارزش سیاست گزارش آسیب‌پذیری، چند سناریوی فرضی را بررسی می‌کنیم.

سناریوی اول: گزارش مشکل کنترل دسترسی

پژوهشگری هنگام بررسی حساب آزمایشی خود متوجه رفتار غیرمنتظره‌ای در دسترسی به اطلاعات می‌شود.

او بدون تلاش برای مشاهده اطلاعات سایر کاربران، موضوع را از طریق کانال امنیتی گزارش می‌کند.

تیم سایت گزارش را دریافت کرده و با داده‌های ساختگی در محیط آزمایشی بررسی می‌کند.

پس از تأیید مشکل، منطق مجوزدهی اصلاح شده و آزمون‌های مرتبط انجام می‌شوند.

در این سناریو، وجود VDP باعث می‌شود پژوهشگر مسیر گزارش و محدودیت‌های بررسی را از ابتدا بشناسد.

سناریوی دوم: گزارش آسیب‌پذیری یک افزونه وردپرس

کاربری متوجه می‌شود نسخه‌ای از یک افزونه عمومی مورد استفاده در سایت دارای ضعف امنیتی شناخته‌شده است.

او اطلاعات مربوط را گزارش می‌کند.

تیم فنی نسخه نصب‌شده را بررسی کرده و در صورت تأیید خطر، به‌روزرسانی یا کنترل جبرانی مناسب را اعمال می‌کند.

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

سناریوی سوم: گزارش ضعف در مدیریت نشست

پژوهشگر رفتار غیرعادی مربوط به پایان‌نیافتن نشست آزمایشی خود را مشاهده می‌کند.

او توضیح می‌دهد در چه شرایطی انتظار پایان نشست وجود داشته و چه رفتاری مشاهده شده است.

تیم توسعه، سیاست انقضای نشست و فرآیند خروج را در محیط آزمایشی بررسی می‌کند.

پس از اصلاح، رفتار نشست در شرایط مختلف آزمایش می‌شود.

سناریوی چهارم: گزارش بحرانی و نیاز به واکنش فوری

یک گزارش معتبر نشان می‌دهد داده‌های حساس ممکن است در شرایط مشخصی در معرض دسترسی غیرمجاز قرار گرفته باشند.

تیم امنیت ابتدا میزان اعتبار گزارش و دامنه تأثیر احتمالی را بررسی می‌کند.

در صورت ضرورت، کنترل‌های موقت برای کاهش خطر اعمال می‌شوند.

هم‌زمان فرآیند پاسخ به حادثه، بررسی لاگ‌ها و تعیین تکلیف اطلاع‌رسانی آغاز می‌شود.

این سناریو نشان می‌دهد VDP باید با برنامه پاسخ به حادثه سازمان هماهنگ باشد.

ارتباط VDP با برنامه پاسخ به حادثه

Vulnerability Disclosure Policy و Incident Response Plan اهداف مرتبط اما متفاوتی دارند.

VDP بر دریافت و مدیریت گزارش ضعف‌های امنیتی تمرکز دارد.

برنامه پاسخ به حادثه برای مدیریت رخدادهای امنیتی واقعی یا مشکوک طراحی می‌شود.

برای مثال، دریافت گزارش درباره یک نقص احتمالی به‌تنهایی به معنای وقوع نفوذ نیست.

اما اگر هنگام بررسی مشخص شود از آن نقص سوءاستفاده شده است، موضوع ممکن است به فرآیند پاسخ به حادثه منتقل شود.

چه زمانی گزارش باید به Incident Response ارجاع شود؟

نشانه‌هایی مانند افشای احتمالی اطلاعات، فعالیت غیرمجاز در حساب‌ها یا شواهد تغییر داده می‌توانند نیازمند بررسی فوری باشند.

سازمان باید معیارهایی برای تشخیص این وضعیت‌ها تعریف کند.

حفاظت از شواهد

در شرایط مشکوک به حادثه، حفظ لاگ‌ها و شواهد اهمیت دارد.

اقدامات اصلاحی باید با نیازهای بررسی امنیتی و جلوگیری از تخریب ناخواسته شواهد هماهنگ شوند.

ارتباط با کاربران

اگر حادثه‌ای واقعی تأیید شود، ممکن است سازمان براساس قوانین و تعهدات مربوط موظف به اطلاع‌رسانی باشد.

وجود VDP جایگزین این مسئولیت‌ها نمی‌شود.

ملاحظات حقوقی و حریم خصوصی در VDP

تدوین سیاست گزارش آسیب‌پذیری علاوه بر جنبه فنی، ملاحظات حقوقی و حریم خصوصی نیز دارد.

شرایط قانونی ممکن است براساس کشور، نوع فعالیت و قراردادهای سازمان متفاوت باشند.

تعیین حدود مجوز

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

ابهام در این بخش می‌تواند باعث سوءبرداشت شود.

محافظت از اطلاعات شخصی

گزارش‌ها نباید به محلی برای جمع‌آوری بی‌دلیل اطلاعات شخصی تبدیل شوند.

سازمان باید حداقل داده لازم را دریافت کند و برای نگهداری، دسترسی و حذف گزارش‌ها قواعد مشخص داشته باشد.

تعهدات قراردادی

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

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

استفاده از مشاوره حقوقی

برای سازمان‌هایی که خدمات حساس یا عمومی ارائه می‌کنند، بازبینی حقوقی سیاست اهمیت ویژه‌ای دارد.

به‌خصوص بخش Safe Harbor، افشای عمومی، تعهدات زمانی و مدیریت داده‌ها باید با حدود اختیار واقعی سازمان هماهنگ باشند.

چگونه موفقیت سیاست گزارش آسیب‌پذیری را ارزیابی کنیم؟

انتشار یک صفحه VDP به‌تنهایی نشان‌دهنده موفقیت برنامه نیست.

سازمان باید بررسی کند فرآیند دریافت و رسیدگی به گزارش‌ها تا چه اندازه مؤثر عمل می‌کند.

میانگین زمان تأیید دریافت گزارش

این شاخص نشان می‌دهد تیم مسئول با چه سرعتی دریافت گزارش‌های امنیتی را تأیید می‌کند.

افزایش غیرعادی این زمان می‌تواند نشان‌دهنده مشکل در مسیر ارتباطی یا ظرفیت تیم باشد.

زمان ارزیابی اولیه

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

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

زمان اصلاح آسیب‌پذیری

زمان اصلاح می‌تواند نشان دهد سازمان با چه سرعتی خطرات تأییدشده را کاهش می‌دهد.

البته مقایسه مستقیم زمان اصلاح مشکلات ساده با آسیب‌پذیری‌های معماری پیچیده، ممکن است گمراه‌کننده باشد.

نرخ گزارش‌های معتبر

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

با این حال، نرخ پایین لزوماً به معنای عملکرد ضعیف برنامه نیست.

ممکن است یک گزارش مهم ارزش امنیتی بیشتری از تعداد زیادی گزارش کم‌اهمیت داشته باشد.

تعداد مشکلات تکراری

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

در چنین شرایطی، اصلاح فرآیند توسعه اهمیت بیشتری از رفع موردی مشکلات دارد.

میزان پایبندی به زمان‌بندی

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

اشتباهات رایج هنگام ایجاد Vulnerability Disclosure Policy

بسیاری از مشکلات VDP ناشی از ضعف در اجرای برنامه هستند، نه صرفاً کیفیت متن سیاست.

۱. کپی‌کردن سیاست سایت‌های دیگر

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

کپی‌کردن زمان‌بندی‌ها، محدوده‌ها و تعهدات بدون بررسی ظرفیت واقعی، می‌تواند مشکل‌ساز شود.

۲. تعریف محدوده بیش از حد گسترده

عبارت‌های مبهم ممکن است باعث شوند پژوهشگران دارایی‌هایی را بررسی کنند که سازمان مجوز لازم برای آن‌ها ندارد.

محدوده باید دقیق و قابل فهم باشد.

۳. نبود مسئول مشخص برای گزارش‌ها

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

تیم باید بداند چه کسی گزارش را دریافت، ارزیابی و پیگیری می‌کند.

۴. بی‌پاسخ‌گذاشتن پژوهشگران

پاسخ‌ندادن طولانی‌مدت می‌تواند اعتماد را کاهش دهد.

حتی زمانی که بررسی کامل نشده است، اطلاع‌رسانی درباره وضعیت می‌تواند مفید باشد.

۵. وعده پاداش بدون برنامه مشخص

اگر سایت برنامه باگ بانتی ندارد، نباید صرفاً برای جذب گزارش وعده مالی بدهد.

شرایط پاداش باید شفاف و قابل اجرا باشند.

۶. انتشار فایل security.txt با اطلاعات قدیمی

آدرس تماس نامعتبر یا تاریخ منقضی‌شده می‌تواند باعث اختلال در گزارش‌دهی شود.

این فایل باید به‌صورت دوره‌ای بازبینی شود.

۷. نبود فرآیند ارجاع گزارش‌های بحرانی

گزارش‌هایی که احتمال خطر فوری برای کاربران دارند، نباید در صف عادی پشتیبانی باقی بمانند.

سازمان باید مسیر مشخصی برای تشدید رسیدگی داشته باشد.

۸. افشای اطلاعات گزارش بدون ضرورت

گزارش آسیب‌پذیری ممکن است حاوی اطلاعاتی باشد که انتشار زودهنگام آن خطر ایجاد کند.

دسترسی به این اطلاعات باید محدود باشد و انتشار عمومی طبق فرآیند هماهنگ انجام شود.

۹. اتکای کامل به ابزارهای خودکار

ابزارهای اسکن و مدیریت آسیب‌پذیری می‌توانند به بررسی گزارش‌ها کمک کنند، اما تحلیل انسانی و شناخت معماری سامانه همچنان ضروری است.

۱۰. بازبینی‌نکردن سیاست پس از تغییرات سایت

تغییر دامنه، انتقال هاست، اضافه‌شدن API یا تغییر مسئول امنیت ممکن است باعث شود بخشی از سیاست قدیمی شود.

VDP باید همراه با تغییرات مهم زیرساخت به‌روزرسانی شود.

بهترین شیوه نگهداری و به‌روزرسانی VDP

سیاست گزارش آسیب‌پذیری یک سند ثابت و بدون تغییر نیست.

با توسعه وب‌سایت، اضافه‌شدن سرویس‌ها و تغییر ساختار سازمان، محدوده و فرآیندهای مربوط نیز ممکن است تغییر کنند.

بازبینی دوره‌ای

بهتر است سازمان یک بازه مشخص برای بازبینی سیاست تعیین کند.

برای مثال، بررسی فصلی می‌تواند برای برخی سایت‌ها مناسب باشد.

علاوه بر بازبینی دوره‌ای، تغییرات مهم زیرساخت نیز باید باعث بررسی مجدد سیاست شوند.

هماهنگی با تیم توسعه

تیم توسعه باید بداند گزارش‌های VDP چگونه به وظایف اصلاحی تبدیل می‌شوند.

ثبت مشکلات امنیتی در سامانه مدیریت پروژه باید با کنترل محرمانگی مناسب همراه باشد.

آموزش تیم پشتیبانی

گاهی پژوهشگر به‌جای کانال رسمی، از طریق تیکت عمومی یا فرم تماس گزارش ارسال می‌کند.

تیم پشتیبانی باید بتواند چنین مواردی را شناسایی و به مسیر درست ارجاع دهد.

مدیریت تغییرات اطلاعات تماس

تغییر مسئول امنیت یا سرویس ایمیل باید در صفحه سیاست و فایل security.txt اعمال شود.

نبود هماهنگی میان این مسیرها ممکن است باعث گم‌شدن گزارش‌ها شود.

تمرین سناریوهای عملیاتی

سازمان می‌تواند با گزارش‌های ساختگی و غیرحساس، فرآیند داخلی رسیدگی را آزمایش کند.

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

این تمرین‌ها به شناسایی ضعف‌های عملیاتی کمک می‌کنند.

آیا سیاست گزارش آسیب‌پذیری برای سایت‌های کوچک ضروری است؟

اندازه سازمان تنها عامل تعیین‌کننده نیاز به VDP نیست.

یک سایت کوچک ممکن است اطلاعات حساس کاربران را پردازش کند و در مقابل، یک سازمان بزرگ نیز ممکن است دارای سرویس‌هایی با حساسیت پایین باشد.

معیار اصلی باید نوع اطلاعات، اهمیت خدمات و سطح ریسک باشد.

سایت‌های شخصی و وبلاگ‌ها

برای وبلاگ‌های ساده، یک کانال گزارش امنیتی و توضیح کوتاه درباره محدوده مجاز ممکن است نقطه شروع کافی باشد.

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

فروشگاه‌های اینترنتی

فروشگاه‌ها معمولاً حساب کاربری، سفارش و اطلاعات تجاری دارند.

به همین دلیل، تعریف فرآیند دریافت و بررسی گزارش امنیتی می‌تواند ارزش قابل توجهی داشته باشد.

سایت‌های سازمانی

سایت‌های سازمانی ممکن است با سامانه‌های داخلی، مدیریت هویت یا APIهای اختصاصی ارتباط داشته باشند.

در این محیط‌ها، تعیین مالک دارایی‌ها و محدوده مجاز اهمیت بیشتری پیدا می‌کند.

پلتفرم‌های SaaS

پلتفرم‌های SaaS ممکن است تعداد زیادی کاربر و مشتری سازمانی داشته باشند.

در چنین شرایطی، مدیریت هماهنگ گزارش‌ها، تفکیک محیط‌ها و حفظ محرمانگی اطلاعات مشتریان ضروری است.

چک‌لیست نهایی ایجاد سیاست گزارش آسیب‌پذیری

پیش از انتشار VDP، بهتر است مجموعه‌ای از کنترل‌های اصلی بررسی شوند.

چک‌لیست سیاست عمومی

1. هدف برنامه به‌صورت روشن توضیح داده شده باشد.

1. دارایی‌های تحت پوشش مشخص باشند.

1. سرویس‌های خارج از محدوده معرفی شده باشند.

1. فعالیت‌های مجاز و ممنوع تعریف شده باشند.

1. روش ارتباطی معتبر و امن وجود داشته باشد.

1. زمان هدف پاسخ اولیه مشخص باشد.

1. فرآیند افشای هماهنگ توضیح داده شده باشد.

1. تعهدات سازمان واقع‌بینانه و قابل اجرا باشند.

1. بخش Safe Harbor از نظر حقوقی بازبینی شده باشد.

1. شرایط قدردانی یا پاداش، در صورت وجود، روشن باشد.

چک‌لیست فنی

1. فرم گزارش از ارتباط HTTPS استفاده کند.

1. دسترسی به گزارش‌های ثبت‌شده محدود باشد.

1. ورودی‌ها و فایل‌های پیوست به‌صورت امن پردازش شوند.

1. اطلاعات حساس غیرضروری در لاگ‌ها ذخیره نشوند.

1. فایل security.txt در مسیر صحیح منتشر شده باشد.

1. تاریخ Expires معتبر و قابل پیگیری باشد.

1. اطلاعات Contact و Policy صحیح باشند.

1. مسیرهای ارتباطی به‌صورت آزمایشی بررسی شده باشند.

چک‌لیست عملیاتی

1. مسئول دریافت گزارش تعیین شده باشد.

1. جانشین مسئول اصلی مشخص باشد.

1. فرآیند ارزیابی اولیه مستند باشد.

1. گزارش‌های بحرانی مسیر رسیدگی فوری داشته باشند.

1. وضعیت گزارش‌ها ثبت و پیگیری شود.

1. فرآیند اصلاح و آزمون مجدد تعریف شده باشد.

1. نحوه هماهنگی با تأمین‌کنندگان مشخص باشد.

1. بازبینی دوره‌ای سیاست برنامه‌ریزی شده باشد.

اجرای این موارد به سازمان کمک می‌کند VDP را از یک صفحه نمایشی به بخشی کاربردی از مدیریت امنیت تبدیل کند.

سؤالات متداول درباره Vulnerability Disclosure Policy

Vulnerability Disclosure Policy چیست؟

Vulnerability Disclosure Policy یا VDP سیاستی رسمی برای دریافت، بررسی و مدیریت گزارش‌های آسیب‌پذیری امنیتی است. این سیاست محدوده بررسی مجاز، روش گزارش‌دهی، زمان پاسخ‌گویی و شرایط هماهنگی برای افشای اطلاعات را مشخص می‌کند.

آیا هر سایتی باید VDP داشته باشد؟

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

آیا VDP با Bug Bounty تفاوت دارد؟

بله. VDP چارچوب گزارش و مدیریت آسیب‌پذیری را مشخص می‌کند، در حالی که Bug Bounty معمولاً شامل پاداش برای گزارش‌های واجد شرایط است. سازمان می‌تواند بدون داشتن برنامه باگ بانتی، سیاست گزارش آسیب‌پذیری منتشر کند.

آیا برای ایجاد VDP باید به پژوهشگران پول پرداخت کنیم؟

خیر. پرداخت پاداش مالی بخش الزامی VDP نیست. سازمان می‌تواند صرفاً گزارش‌ها را دریافت و بررسی کند و در صورت تمایل، با رضایت پژوهشگر از او قدردانی کند.

فایل security.txt چه کاربردی دارد؟

security.txt یک فایل متنی استاندارد است که روش تماس با تیم امنیت و اطلاعات مرتبط با سیاست گزارش آسیب‌پذیری را معرفی می‌کند. این فایل به پژوهشگران کمک می‌کند مسیر مناسب گزارش‌دهی را پیدا کنند.

محل استاندارد فایل security.txt کجاست؟

در وب‌سایت‌ها، مسیر استاندارد آن /.well-known/security.txt است. فایل باید از طریق HTTPS و مطابق قالب مشخص‌شده قابل دریافت باشد.

آیا داشتن security.txt برای اجرای VDP کافی است؟

خیر. security.txt فقط اطلاعات لازم برای یافتن مسیر گزارش‌دهی را ارائه می‌کند. سازمان همچنان به سیاست شفاف، مسئول رسیدگی، فرآیند بررسی و روش اصلاح آسیب‌پذیری نیاز دارد.

Safe Harbor در VDP چه معنایی دارد؟

Safe Harbor به موضع و تعهدات اعلام‌شده سازمان در قبال پژوهشگران دارای حسن نیت و فعالیت‌های مجاز اشاره دارد. این بخش نباید با مصونیت حقوقی مطلق اشتباه گرفته شود و باید با قوانین و حدود اختیار سازمان هماهنگ باشد.

بهترین زمان پاسخ به گزارش آسیب‌پذیری چقدر است؟

زمان پاسخ باید براساس ظرفیت سازمان تعیین شود. برای نمونه، تأیید دریافت طی یک تا سه روز کاری می‌تواند هدف مناسبی برای بعضی سایت‌ها باشد. گزارش‌های دارای خطر فوری باید براساس فرآیند پاسخ اضطراری بررسی شوند.

آیا پژوهشگر می‌تواند بدون اجازه سایت را تست کند؟

انتشار یک VDP ممکن است برای فعالیت‌های مشخص و محدود، شرایط مجوز را تعریف کند؛ اما این موضوع اجازه نامحدود برای آزمایش ایجاد نمی‌کند. پژوهشگر باید محدوده و شرایط اعلام‌شده، قوانین و حقوق اشخاص ثالث را رعایت کند.

آیا می‌توان VDP را در وردپرس ایجاد کرد؟

بله. می‌توان یک صفحه عمومی برای سیاست گزارش آسیب‌پذیری ایجاد کرد، روش تماس امن معرفی کرد و فایل security.txt را در مسیر استاندارد قرار داد. همچنین باید فرآیند داخلی دریافت و مدیریت گزارش‌ها مشخص باشد.

اگر گزارش آسیب‌پذیری اشتباه باشد چه کنیم؟

تیم فنی باید گزارش را بررسی کند و در صورت امکان، نتیجه را محترمانه و روشن به پژوهشگر اطلاع دهد. گزارش نامعتبر نباید به‌صورت خودکار نشانه سوءنیت پژوهشگر تلقی شود.

آیا گزارش‌های امنیتی باید محرمانه بمانند؟

جزئیات آسیب‌پذیری‌های اصلاح‌نشده و اطلاعات حساس باید مطابق سیاست امنیتی محافظت شوند. انتشار عمومی بهتر است براساس فرآیند افشای هماهنگ انجام شود و نیازهای حفاظتی کاربران را در نظر بگیرد.

آیا VDP جایگزین تست نفوذ است؟

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

آیا ایجاد VDP باعث افزایش حملات علیه سایت می‌شود؟

انتشار سیاست به‌تنهایی اجازه سوءاستفاده ایجاد نمی‌کند و اثر آن بر میزان فعالیت‌های امنیتی به شرایط سایت وابسته است. تعریف محدوده روشن، محدودیت‌های آزمایش و کانال گزارش امن می‌تواند به مدیریت بهتر ارتباط با پژوهشگران کمک کند.

آیا سیاست گزارش آسیب‌پذیری باید به زبان انگلیسی باشد؟

الزام عمومی برای انگلیسی‌بودن سیاست وجود ندارد. بهتر است زبان سند با کاربران و پژوهشگران هدف متناسب باشد. سایت‌هایی که مخاطب بین‌المللی دارند، می‌توانند نسخه انگلیسی نیز ارائه کنند.

جمع‌بندی: چگونه یک سیاست گزارش آسیب‌پذیری مؤثر ایجاد کنیم؟

Vulnerability Disclosure Policy یکی از اجزای مهم مدیریت امنیت وب‌سایت و ارتباط مسئولانه با پژوهشگران امنیتی است.

این سیاست مشخص می‌کند آسیب‌پذیری‌های احتمالی چگونه گزارش شوند، چه فعالیت‌هایی مجاز هستند و سازمان چگونه مشکلات تأییدشده را بررسی و اصلاح می‌کند.

مهم‌ترین ارزش VDP در ایجاد یک فرآیند قابل اعتماد و قابل اجرا برای مدیریت گزارش‌های امنیتی است.

بدون چنین فرآیندی، ممکن است گزارش‌های مهم به مسئول مناسب نرسند، بررسی آن‌ها با تأخیر انجام شود یا هماهنگی لازم برای افشای مسئولانه شکل نگیرد.

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

در ادامه، سازمان باید فرآیند دریافت، ارزیابی، اولویت‌بندی، اصلاح و آزمون مجدد آسیب‌پذیری‌ها را طراحی کند.

انتشار فایل security.txt نیز می‌تواند شناسایی مسیر گزارش‌دهی را ساده‌تر کند؛ اما جایگزین سیاست عمومی و فرآیند رسیدگی نیست.

یکی از نکات مهم این است که VDP باید با ظرفیت واقعی سازمان هماهنگ باشد.

یک سایت کوچک الزاماً به ساختار پیچیده مدیریت گزارش نیاز ندارد، اما حتی یک سیاست ساده نیز باید دقیق، قابل اعتماد و قابل اجرا باشد.

در مقابل، سازمان‌های بزرگ باید ارتباط VDP را با مدیریت آسیب‌پذیری، توسعه امن نرم‌افزار، پاسخ به حادثه و مدیریت تأمین‌کنندگان در نظر بگیرند.

در نهایت، یک سیاست گزارش آسیب‌پذیری موفق تنها سندی برای انتشار در سایت نیست؛ بلکه تعهدی عملی به دریافت مسئولانه گزارش‌ها، اصلاح مشکلات امنیتی و حفاظت بهتر از کاربران است.

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