Coordinated vulnerability disclosureNCSC.nl
۱. مقدمه
جامعه روزبه‌روز دیجیتالی‌تر می‌شود. امروزه تقریباً همه فرایندها در جایی شامل استفاده از رایانه‌اند، از تلفن همراه گرفته تا نرم‌افزارهای تخصصی. هرچند این تحول فرصت‌های جدید بسیاری ایجاد می‌کند، آسیب‌پذیری‌ها در سامانه‌های فناوری اطلاعات می‌توانند تأثیر بزرگی داشته باشند. در نتیجه، دانش درباره این آسیب‌پذیری‌ها باید به‌طور مؤثر مدیریت شود.
شماری از سازمان‌ها در اوایل سال ۲۰۱۳ شروع به انتشار سیاست درباره نحوه گزارش آسیب‌پذیری‌ها کردند. پس از رایزنی با این طرف‌ها، مرکز ملی امنیت سایبری (National Cyber Security Centre، یا NCSC) تحولات را در قالب «رهنمودهایی برای دستیابی به رویه Responsible Disclosure» («Leidraad om te komen tot een praktijk van Responsible Disclosure»؛ «رهنمودها») خلاصه کرد. شرکت‌ها از طریق این سیاست نشان می‌دهند که پذیرای دریافت گزارش‌های آسیب‌پذیری بیرونی‌اند، پیش‌شرط‌های خود را شرح می‌دهند و وعده می‌دهند. این فرایند وضوح و محیطی تا حدی امن برای طرف‌های گزارش‌دهنده ایجاد کرد تا آسیب‌پذیری‌ها را بررسی و گزارش کنند بی‌آنکه مستقیماً مرتکب جرم کیفری شوند. در نشست سطح بالای اتحادیه اروپا درباره امنیت سایبری در سال ۲۰۱۶، ۲۹ سازمان با امضای بیانیه افشای هماهنگ آسیب‌پذیری (Coordinated Vulnerability Disclosure Manifesto)1 که CIO Platform Netherlands و Rabobank با همکاری NCSC آغاز کردند، اهمیت سیاستی برای رسیدگی به آسیب‌پذیری‌ها را دوباره تأیید کردند.
افشای هماهنگ آسیب‌پذیری (Coordinated Vulnerability Disclosure، یا CVD) اهمیت زیادی برای طرف‌های دولتی و خصوصی ثابت کرده است. آن‌ها در عمل روزمره به عملکرد بی‌وقفه سامانه‌های اطلاعاتی بسیار وابسته‌اند. گزارش آسیب‌پذیری‌ها در سامانه‌هایشان در سال‌های اخیر به بهبود امنیت و تداوم سامانه‌ها کمک کرده است، از یک سو با رفع آسیب‌پذیری‌ها و از سوی دیگر با مشارکت در آگاهی عمومی شرکت‌های هلندی از امنیت فناوری اطلاعات.
در سال‌های اخیر روشن شده که طرف‌های گزارش‌دهنده آماده‌اند در چارچوب شرایط سیاست CVD که سازمان‌ها تنظیم کرده‌اند کار کنند. گزارش‌ها به‌طور مستقیم یا غیرمستقیم توسط طرف‌های گزارش‌دهنده به سازمان‌ها داده می‌شود. رویه افشای مسئولانه نشان داده که طرف‌های گزارش‌دهنده خوش‌نیت و سازمان‌های آسیب‌پذیر توانسته‌اند همکاری کنند و بدین‌ترتیب گام بعدی را در افزایش امنیت شبکه‌ها و سامانه‌های اطلاعاتی بردارند.
برای این بازنگری، بار دیگر با گروهی گسترده و متنوع از طرف‌های گزارش‌دهنده، طرف‌های خصوصی و دولتی، و همچنین با دادستانی و پلیس ملی گفت‌وگو کردیم. این گفت‌وگوها رویه کنونی را تأیید کرد و به افزودنی‌ها و بهبودهایی انجامید. مهم‌ترین نکته جدید قابل‌توجه، ارتباط میان گزارش‌دهنده آسیب‌پذیری و سازمان، و نیز با طرف‌های دیگر پس از رفع آسیب‌پذیری است.
فصل‌های بعد تعریف CVD، اجزای سازنده یک سیاست CVD و فرایند ارتباط را بررسی می‌کنند.
حاشیه: رهنمودهای پیشین از اصطلاح «responsible disclosure» (افشای مسئولانه) استفاده می‌کردند که در آن زمان اصطلاح رایج برای این رویه بود. در این میان روشن شده که این اصطلاح تأکید بیش از حد بر مسئولیت طرف گزارش‌دهنده دارد، در حالی که اصل اساسی این است که طرف گزارش‌دهنده و سازمانِ بالقوه آسیب‌پذیر باید شرکای برابر در گفت‌وگو باشند. این نگرش در اصطلاح رایج کنونی «Coordinated Vulnerability Disclosure» (CVD) بهتر بازتاب می‌یابد که نام به‌کاررفته در استانداردهای ISO 29147 و 30111 درباره این فرایند نیز هست.
۲. آسیب‌پذیری هماهنگ
در ۳۰ سال گذشته روش‌های گوناگونی برای افزایش آگاهی از آسیب‌پذیری‌ها در سامانه‌های فناوری اطلاعات به کار رفته است. نمونه‌ها عبارت‌اند از:
«Full Disclosure» (افشای کامل)، کاملاً عمومی‌کردن یک آسیب‌پذیری؛
«Non-disclosure» (عدم افشا)، فروش یا استفاده شخصی از آسیب‌پذیری؛
«Coordinated Vulnerability Disclosure» (CVD)، افشای هماهنگ یک آسیب‌پذیری.
رویه اخیر صراحتاً ترجیح داده می‌شود.
جامعه فناوری اطلاعات تمایل زیادی به اشتراک دانش و تجربه نشان داده است. جست‌وجوی همکاری با این جامعه می‌تواند به بهبود امنیت کلی سامانه‌ها کمک کند.
هدف افشای هماهنگ آسیب‌پذیری
هدف CVD مشارکت در امنیت سامانه‌های فناوری اطلاعات با اشتراک دانش درباره آسیب‌پذیری‌هاست. در CVD دانش با یک یا چند سازمان بالقوه آسیب‌پذیر به اشتراک گذاشته می‌شود تا در همکاری با طرف گزارش‌دهنده به راه‌حلی مشترک برای آسیب‌پذیری یافته‌شده رسید. مهم است که سازمان‌های آسیب‌دیده زمان کافی برای رفع هر آسیب‌پذیری یا محافظت از سامانه‌ها داشته باشند تا زیان یا خسارت تا حد امکان محدود یا جلوگیری شود. سنگ بنای فرایند، افشای دانش درباره آسیب‌پذیری‌ها پس از رفع آن‌هاست.
در CVD ضروری است که همه طرف‌ها از توافق‌های مربوط به نحوه گزارش آسیب‌پذیری و نحوه رسیدگی به آن پیروی کنند. کمک می‌کند اگر سازمانی پیش‌شرط‌ها را از پیش منتشر کند، مانند اینکه کدام سامانه‌ها در دامنه‌اند و چه نوع پژوهشی می‌تواند انجام شود. یک اصل مهم برای این پیش‌شرط‌ها این است که سازمان در اصل علیه طرف گزارش‌دهنده شکایت نمی‌کند و اقدام حقوقی دیگری نمی‌کند، اگر بررسی و گزارش‌دهی در چارچوب شرایط تعیین‌شده انجام شود. این رهنمودها به سازمان‌ها راهنمایی می‌دهند تا سیاست خود را برای تجسم اصول CVD تنظیم کنند.
همان‌گونه که نام نشان می‌دهد، در CVD این محوری است که سازمان و طرف گزارش‌دهنده با یکدیگر هماهنگ شوند. از این نظر، باید تا حد امکان حلقه‌های کمی میان فرد گزارش‌دهنده آسیب‌پذیری و فردی در سازمان که مسئول حل مسئله است وجود داشته باشد.
اگر آسیب‌پذیری بر سامانه‌های زیادی اثر بگذارد، ممکن است مهم باشد چند طرف هم‌زمان مطلع شوند. در این صورت، NCSC یا طرف‌های دیگر در جامعه امنیتی می‌توانند از نقش هماهنگ‌کننده از فرایند CVD پشتیبانی کنند.
۳. حوزه‌های مسئولیت
هدف از پیگیری سیاست CVD این است که طرف‌های گزارش‌دهنده و سازمان برای کاهش آسیب‌پذیری‌ها در سامانه‌های فناوری اطلاعات با هم کار کنند. اجرای این سیاست باید مکمل اقدامات موجود درباره امنیت اطلاعات دیده شود. بازیگران مختلف هر کدام نقش و مسئولیت‌های خود را دارند. این‌ها در ادامه به تفصیل بیشتری توضیح داده می‌شوند.
سازمانی که مالک/مدیر یک سامانه است
سازمانی که مالک/مدیر یا تأمین‌کننده یک سامانه است در درجه اول مسئول امنیت آن سامانه است. به عبارت دیگر، سازمان مسئول پیگیری گزارش آسیب‌پذیری نیز هست.
سازمان می‌تواند انتخاب کند که سیاست CVD خود را با استفاده از این رهنمودها تنظیم کند و آن سیاست را با طرف‌های گزارش‌دهنده بالقوه در میان بگذارد. با انتشار سیاست CVD، سازمان‌ها تمایل خود را به دریافت اطلاعات درباره آسیب‌پذیری‌ها نشان می‌دهند.
طرفی که سیاست CVD وضع می‌کند می‌تواند به این اصل متعهد شود که در صورت رعایت قواعد حاکم بر سیاست، به پلیس شکایت نخواهد کرد.
وقتی طرف گزارش‌دهنده آسیب‌پذیری‌ای را گزارش کرد، مسئولیت بر عهده سازمان است. مهم است بدانیم طرف گزارش‌دهنده اغلب فردی بیرون از سازمان است. این طرف دید مستقیمی از فرایندهای داخلی که ممکن است پس از گزارش آسیب‌پذیری آغاز شوند ندارد. در نتیجه، طرف‌های گزارش‌دهنده از اطلاع‌رسانی درباره تحولات در حل آسیب‌پذیری قدردانی می‌کنند. این ارتباط مستمر برای ایجاد انتظارات درست درباره پیگیری و به‌موقع‌بودن راه‌حل نیز مهم است.
طرفی که آسیب‌پذیری را گزارش می‌دهد
طرف گزارش‌دهنده به‌نحوی توانسته آسیب‌پذیری‌ای را شناسایی کند و می‌خواهد با رفع این آسیب‌پذیری و احتمالاً عمومی‌کردن آن در مرحله‌ای بعد به امنیت سامانه‌های فناوری اطلاعات کمک کند. طرف گزارش‌دهنده ممکن است چیزی را از طریق مشاهده منفعلانه یا با آزمایش فعال سامانه فناوری اطلاعات کشف کرده باشد. البته این طرف مسئول اقدامات خود و نحوه کشف آسیب‌پذیری است. مسئولیت خود طرف گزارش‌دهنده است که از شرایط تعیین‌شده توسط سازمان در سیاست CVD خود آگاه باشد. بیشتر دولت‌ها و شرکت‌ها سیاست‌های CVD خود را در وب‌سایت‌هایشان منتشر کرده‌اند.
با این حال، یافتن آسیب‌پذیری‌ها ممکن است شامل نقض قانون باشد. در زمینه CVD، سازمان و طرف گزارش‌دهنده می‌توانند توافق کنند که درباره هیچ اقدام مجرمانه‌ای شکایت نکنند. در این خصوص، سیاست CVD منتشرشده توسط سازمان اصل راهنماست. طرفین همچنین می‌توانند توافق کنند که هیچ اقدام مدنی انجام نشود.
اگر گمان نقض قانون توسط طرف گزارش‌دهنده وجود داشته باشد، سیاست CVD پیش از هر چیز می‌تواند به جلوگیری از گزارش‌شدن گزارش‌دهنده به مقامات کمک کند. این رویه کاملاً به پیش‌شرط‌های سیاست که سازمان از طرف گزارش‌دهنده می‌خواهد رعایت کند و به اینکه آیا این رعایت حاصل شده یا نه بستگی دارد، احتمالاً با وعده‌ای متناظر مبنی بر عدم طرح شکایت کیفری تا زمانی که طرف در چارچوب شرایط سیاست عمل کند. اگر به پلیس گزارش داده شود، وجود و رعایت سیاست CVD در هلند یک شرط مرتبط است که دادستان هنگام تصمیم‌گیری درباره اینکه آیا تحقیق کیفری آغاز کند و/یا تعقیب کند در نظر می‌گیرد. در اصل، پلیس و دادستانی (OM) تحقیق کیفری آغاز نمی‌کنند اگر طرف گزارش‌دهنده به‌وضوح از قواعد سیاست CVD سازمان مربوط پیروی کرده باشد. با این حال، دادستانی و پلیس می‌توانند پرونده را بیشتر بررسی کنند اگر نشانه‌هایی وجود داشته باشد که طرف گزارش‌دهنده آگاهانه یا ناآگاهانه در اقدامات خود بیش از حد پیش رفته و/یا از سیاست CVD پیروی نکرده است. بر پایه این بررسی، دادستانی می‌تواند تصمیم بگیرد که آیا تعقیب کند.
دادستانی نامه‌ای سیاستی منتشر کرده که در آن به جنبه‌هایی که در تصمیم به تحقیق و/یا تعقیب مهم‌اند به‌طور مشخص‌تر می‌پردازد. برای مثال، اینکه آیا اقدامات طرف گزارش‌دهنده در خدمت یک منفعت عمومی مهم بوده، آیا طرف نامتناسب عمل کرده و آیا طرف شاید می‌توانسته به شیوه‌ای دیگر کم‌شدت‌تر عمل کند. نامه سیاستی مربوط این جنبه‌ها را بیشتر توضیح می‌دهد.2 رویه قضایی مرتبط از ۲۰۱۳3 نشان می‌دهد که این جنبه‌ها در دادگاه نیز در نظر گرفته می‌شوند اگر سازمانی سیاست CVD نداشته باشد.
۴. اجزای سازنده فرایند افشای هماهنگ آسیب‌پذیری
اجزای سازنده برای شکل‌دادن به فرایند CVD برای سازمان، گزارش‌دهنده و NCSC در زیر آمده است.
سازمان
ترویج CVD از سازمانی آغاز می‌شود که مالک سامانه‌های فناوری اطلاعات است یا محصول/سامانه فناوری اطلاعات تأمین می‌کند. به هر حال، این سازمان در درجه اول مسئول امنیت اطلاعات این سامانه‌های فناوری اطلاعات است. برای همکاری مؤثر با طرف‌های مختلف در حل آسیب‌پذیری‌ها، سازمان می‌تواند تصمیم بگیرد سیاست CVD را تنظیم و منتشر کند. تنظیم سیاست CVD خود به سازمان اجازه می‌دهد نشان دهد چگونه با گزارش‌های آسیب‌پذیری برخورد می‌کند. به این ترتیب، سازمان همچنین می‌تواند شیوه‌ای را که مایل به دریافت اعلان‌هاست شکل دهد. چنین فرایندی را می‌توان به شرح زیر سازمان داد:
سازمان یک سیاست CVD وضع و منتشر می‌کند.
در این سیاست، سازمان قواعد روشنی برای پژوهشی که طرف‌های گزارش‌دهنده می‌توانند انجام دهند ارائه می‌دهد، مانند اینکه چه فنونی مجازند و کدام سامانه‌ها در دامنه یا خارج از دامنه‌اند.
سازمان گزارش‌دادن را برای طرف گزارش‌دهنده آسان می‌کند. یک گزینه استفاده از روش گزارش‌دهی استاندارد است؛ مثلاً یک نشانی ایمیل مشخص یا فرم آنلاین. علاوه بر این، سازمان می‌تواند تصمیم بگیرد گزارش‌های ناشناس را بپذیرد یا نه.
سازمان ظرفیت داخلی کنار می‌گذارد و فرایندی برای پاسخ مناسب به گزارش‌ها برقرار می‌کند. توصیه می‌شود فرایندی برقرار شود که با آن هر آسیب‌پذیری یافته‌شده به‌درستی رفع شود. در این خصوص، منشأ گزارش بی‌اهمیت است. آسیب‌پذیری ممکن است برای مثال توسط کارمند داخلی یا در یک آزمایش نیز شناسایی شده باشد.
تجربه عملی نشان می‌دهد که پس از انتشار اولیه سیاست CVD علاقه بیشتری به گزارش آسیب‌پذیری‌ها به سازمان وجود خواهد داشت. سازمان باید هنگام برنامه‌ریزی ظرفیت (اضافی) این را در نظر بگیرد.
وقتی سازمان گزارش آسیب‌پذیری را دریافت می‌کند، اطمینان می‌یابد که گزارش هرچه زودتر به بخشی می‌رسد که برای ارزیابی و رسیدگی به گزارش مناسب‌تر است.
سازمان تأییدیه دریافت گزارش را به طرف گزارش‌دهنده می‌فرستد، ترجیحاً به‌صورت دیجیتال امضاشده تا بر اولویت تأکید شود.
متعاقباً، سازمان با طرف گزارش‌دهنده رایزنی می‌کند تا دوره‌ای را که هر انتشاری در آن انجام می‌شود تعیین کند. این دوره به‌شدت به ماهیت آسیب‌پذیری و نوع سامانه بستگی دارد.
به‌عنوان راهنما، دوره‌ای حدود ۶۰ روز اغلب برای آسیب‌پذیری‌های نرم‌افزاری به کار می‌رود. رفع آسیب‌پذیری‌ها در سخت‌افزار دشوارتر است؛ می‌توان از راهنمای ۶ ماه استفاده کرد.
ممکن است مطلوب باشد این دوره با توافق دوجانبه بسته به اینکه چه تعداد یا چه تعداد اندک سامانه فناوری اطلاعات به سامانه‌ای که آسیب‌پذیری‌اش گزارش شده وابسته‌اند یا اینکه آسیب‌پذیری آسان‌تر یا دشوارتر قابل‌حل است، تمدید یا کوتاه شود.
ممکن است حل آسیب‌پذیری دشوار یا غیرممکن باشد یا هزینه‌های بالایی در حل آن دخیل باشد. در چنین مواردی، سازمان ممکن است موافقت کند آسیب‌پذیری را خطر پذیرفته‌شده بداند و آن را رفع نکند، احتمالاً با رایزنی با طرف گزارش‌دهنده.
سازمان طرف گزارش‌دهنده را از پیشرفت فرایند مطلع نگه می‌دارد.
علاوه بر این، سازمان می‌تواند پیشنهاد کند که طرف گزارش‌دهنده برای انتشار آسیب‌پذیری علناً مورد قدردانی قرار گیرد. همچنین می‌توان افشای مشترک به دنیای بیرون را انتخاب کرد.
ترجیحاً در برابر گزارش آسیب‌پذیری‌ها در سامانه‌ها به طرف گزارش‌دهنده پاداش داده شود اگر طرف از قواعد سیاست CVD پیروی کرده باشد. مبلغ پاداش ممکن است به کیفیت گزارش بستگی داشته باشد. پاداش‌دادن به طرف گزارش‌دهنده می‌تواند رابطه بهتری میان آن طرف و سازمان ایجاد کند و نیز تمایل مردم به ارائه گزارش‌های جدید مطابق با سیاست CVD را افزایش دهد.
با رایزنی با طرف گزارش‌دهنده، سازمان می‌تواند موافقت کند که جامعه گسترده‌تر فناوری اطلاعات را درباره آسیب‌پذیری مطلع کند اگر محتمل باشد که آسیب‌پذیری در جاهای دیگر نیز وجود دارد.
سازمان در سیاست CVD خود می‌تواند خود را به این اصل متعهد کند که اگر طرف گزارش‌دهنده از قواعد مندرج در سیاست پیروی کرده باشد به پلیس شکایت نخواهد کرد.
طرف گزارش‌دهنده
طرف گزارش‌دهنده کلید یک فرایند CVD موفق است. این طرف به‌نحوی توانسته آسیب‌پذیری‌ای را شناسایی کند و می‌خواهد با اینکه سازمانی این آسیب‌پذیری را رفع کند و عمومی شود به امنیت سامانه‌های فناوری اطلاعات کمک کند. با این کار، طرف‌های گزارش‌دهنده می‌پذیرند که می‌توانند با افشای هماهنگ آسیب‌پذیری‌ها سهم مهمی در جامعه داشته باشند. برای دستیابی به فرایند CVD موفق، اجزای سازنده زیر برای طرف گزارش‌دهنده مهم‌اند:
طرف گزارش‌دهنده مسئول اقدامات خود است و هنگام بررسی و گزارش آسیب‌پذیری‌ها باید اصول تناسب و نیز تفویض (subsidiarity) را رعایت کند. به عبارت دیگر، طرف گزارش‌دهنده نباید بیش از آنچه برای نشان‌دادن آسیب‌پذیری لازم است انجام دهد و باید همواره ابتدا آسیب‌پذیری را به مالک سامانه/اطلاعات گزارش دهد.
طرف گزارش‌دهنده باید مسئله را هرچه زودتر گزارش دهد تا از کشف آسیب‌پذیری و بهره‌برداری از آن توسط طرف‌های بدخواه جلوگیری کند.
طرف گزارش‌دهنده باید گزارش را به‌صورت محرمانه به سازمان بدهد تا از دسترسی دیگران به این اطلاعات جلوگیری کند.
طرف گزارش‌دهنده نمی‌تواند ارائه گزارش یا ارائه بیشتر اطلاعات را به پاداش مشروط کند. ابتدای اعطای پاداش در صورت گزارش بر عهده سازمان دریافت‌کننده است که می‌تواند پیش‌شرط‌ها را در سیاست منتشرشده خود شرح دهد.
طرف گزارش‌دهنده و سازمان توافق‌های روشنی درباره افشای آسیب‌پذیری می‌کنند. اگر بیش از یک سازمان درگیر باشد، اصل اساسی این است که آسیب‌پذیری‌ها فقط در صورتی منتشر شوند که همه سازمان‌ها با این امر موافق باشند. انجام این توافق‌ها در مرحله اولیه توصیه می‌شود.
طرف گزارش‌دهنده و سازمان درگیر می‌توانند درباره اطلاع‌رسانی به جامعه گسترده‌تر فناوری اطلاعات توافق کنند. مثلاً این وضعیت ممکن است برای آسیب‌پذیری‌ای (چه شناخته‌شده چه نه) که معلوم است در بیش از یک مکان وجود دارد صدق کند. مرکز ملی امنیت سایبری (NCSC) می‌تواند در این فرایند درگیر شود تا از گروه‌های هدف دولت مرکزی و زیرساخت حیاتی پشتیبانی کند یا در صورت آسیب‌پذیری‌ای که بر سامانه‌های زیادی اثر می‌گذارد چند طرف را مطلع کند.
NCSC
فرایند CVD در درجه اول موضوع سازمان‌ها و طرف‌های گزارش‌دهنده است. با این حال، NCSC استفاده از فرایند CVD را تشویق می‌کند. با رایزنی با طرف گزارش‌دهنده و سازمان، NCSC همچنین می‌تواند در اشتراک اطلاعات درباره آسیب‌پذیری با مخاطبان خود درگیر شود تا خطرهای امنیتی بیشتر ناشی از آسیب‌پذیری را محدود کند.
اگر گزارش آسیب‌پذیری آن‌گونه که طرف گزارش‌دهنده انتظار دارد پیش نرود، یا اگر ترجیح دهد آسیب‌پذیری را مستقیماً به سازمان گزارش ندهد، می‌تواند با NCSC تماس بگیرد.4 در این صورت، NCSC در صورت لزوم می‌تواند به‌عنوان واسطه عمل کند.
مالک سامانه فناوری اطلاعات در همه حال مسئول امنیت سامانه است. NCSC نمی‌تواند مالک سامانه را مجبور به رفع آسیب‌پذیری کند و نمی‌تواند تضمین کند که مالک علیه طرف گزارش‌دهنده اقدام حقوقی نخواهد کرد. در نتیجه، طرف گزارش‌دهنده باید هنگام جست‌وجو و گزارش آسیب‌پذیری اجزای سازنده پیش‌گفته برای سازمان‌ها و طرف‌های گزارش‌دهنده را در نظر بگیرد. طرف گزارش‌دهنده می‌تواند انتظار داشته باشد NCSC نهایت تلاش خود را برای رفع آسیب‌پذیری بکند و با گزارش محرمانه برخورد کند. NCSC هیچ داده شخصی را به اشتراک نمی‌گذارد مگر اینکه قانوناً ملزم باشد.
در صورت امکان، NCSC اطلاعات به‌دست‌آمده درباره آسیب‌پذیری‌ها را با رایزنی با سازمان‌ها و طرف‌های گزارش‌دهنده برای اشتراک بیشتر دانش با جامعه فناوری اطلاعات به کار می‌برد. برای مثال، می‌تواند این کار را با انتشار بخشی از اطلاعات، نوشتن یا به‌روزکردن برگه اطلاعات (fact sheet) یا کتاب سفید (white paper) یا اطلاع‌رسانی به سازمان‌های مشخص انجام دهد.
بسته به سازمان مربوط و ماهیت آسیب‌پذیری احراز‌شده، NCSC تلاش می‌کند آسیب‌پذیری را به توجه سازمان مربوط برساند. با این حال، مالک سامانه فناوری اطلاعات مورد نظر مسئول سامانه باقی می‌ماند.
هر جا ممکن و لازم باشد، NCSC به سازمان مربوط درباره نحوه رفع آسیب‌پذیری مشاوره می‌دهد.
NCSC با گزارش‌ها محرمانه برخورد می‌کند و داده‌های شخصی طرف‌های گزارش‌دهنده یا سازمان دریافت‌کننده را بدون رضایت به اشتراک نمی‌گذارد، مگر اینکه از تکلیف قانونی ناشی شود.
هر جا ممکن باشد، NCSC طرف گزارش‌دهنده را از تحولات در تماس با سازمان و رفع آسیب‌پذیری مطلع نگه می‌دارد.
در مواردی که گزارشی به NCSC داده می‌شود، NCSC می‌کوشد طرف گزارش‌دهنده یا طرف گزارش‌دهنده بالقوه و سازمان را با یکدیگر در تماس قرار دهد.
اگر طرف گزارش‌دهنده آسیب‌پذیری‌ای در یک محصول نرم‌افزاری یا آسیب‌پذیری‌ای که بر سامانه‌های مختلف زیادی اثر می‌گذارد یافته باشد، مثلاً، طرف گزارش‌دهنده می‌تواند از NCSC بخواهد رفع و افشای آسیب‌پذیری را هماهنگ کند.
NCSC همراه با طرف گزارش‌دهنده، شرکا، توسعه‌دهندگان و/یا توسعه‌دهندگان نرم‌افزار و سایر تیم‌های امنیتی به تحلیل، رفع یا وادارکردن به رفع، هماهنگی و افشای آسیب‌پذیری به شیوه‌ای کنترل‌شده کمک می‌کند. همه این فرایند با رایزنی نزدیک با طرف گزارش‌دهنده‌ای انجام می‌شود که آسیب‌پذیری را یافته است.
سیاست CVD می‌کوشد میان اهمیت افشای آسیب‌پذیری‌ها هرچه زودتر، تا بتوان اقداماتی کرد، و اهمیت اینکه توسعه‌دهندگان و تأمین‌کنندگان زمان کافی برای رفع آسیب‌پذیری داشته باشند توازن برقرار کند. برای این فرایند، NCSC از مهلت استاندارد ۶۰ روز میان گزارش و افشای عمومی استفاده می‌کند. با این حال، ممکن است شرایطی باشد که در آن تصمیم گرفته شود این دوره تمدید یا کوتاه شود.
NCSC اطلاعات درباره آسیب‌پذیری را فقط پس از رایزنی با طرف گزارش‌دهنده با اشخاص ثالث به اشتراک می‌گذارد. در این زمینه ضروری است که NCSC همکاری کند و بنابراین اطلاعات درباره آسیب‌پذیری را با ذی‌نفعان به اشتراک بگذارد تا آسیب‌پذیری را به شیوه‌ای هماهنگ افشا کند. NCSC بدین‌وسیله اطمینان می‌دهد که طرف‌های درست می‌توانند بر رفع آسیب‌پذیری کار کنند، به محدودکردن هرگونه زیان یا خسارت کمک کند و به جلب توجه به آسیب‌پذیری یافته‌شده یاری رساند.
۵. ارتباط و فرایند افشا
پنج سال تجربه نشان داده که ارتباط روشن سنگ بنای فرایند CVD موفق است. نکاتی برای توجه پیش از، در حین و پس از فرایند CVD وجود دارد.
ارتباط درباره فرایند افشا
انتشار سیاست CVD نخستین گام در ارتباط درباره فرایند است. با انتشار علنی سیاست، از طرف‌های گزارش‌دهنده دعوت می‌شود سازمان را از هر آسیب‌پذیری یافته‌شده مطلع کنند.
از یک سو، سازمان می‌تواند شرایطی برای پژوهشی که برای کشف آسیب‌پذیری‌ها انجام می‌شود و شیوه‌ای که در آن تماس جست‌وجو می‌شود تعیین کند. از سوی دیگر، سازمان می‌تواند خود را به این اصل متعهد کند که اگر قواعد سیاست رعایت شود به پلیس شکایت نخواهد کرد. این رویکرد از موقعیت طرف گزارش‌دهنده محافظت می‌کند.
سیاست CVD ممکن است در تاریخی بعد تغییر یا به‌روز شود. مهم است که درباره تغییرات در این خصوص روشن بود. طرف‌های گزارش‌دهنده منفعت دارند که بدانند چه چیزی و چه زمانی تغییر کرده است. برای مثال، می‌توان تغییرات را با گنجاندن تاریخ انتشار در ابتدای سیاست CVD، با شرح خلاصه تغییرات زیر سیاست CVD یا با نگهداری بایگانی نسخه‌های قدیمی سیاست CVD روشن کرد.
سیاست CVD می‌تواند رهنمودهایی درباره چگونگی ارتباط در طول فرایند ارائه دهد، مانند اشاره به به‌روزرسانی‌های منظم از طریق ایمیل یا درگاه وب. علاوه بر این، سیاست CVD می‌تواند شرح دهد که چگونه می‌توان از گزارش‌دهنده با ذکر نام او در یک به‌روزرسانی، پذیرش در تالار مشاهیر (hall of fame) یا هر شکل دیگری از پاداش قدردانی کرد.
ارتباط در طول فرایند افشا
طرف گزارش‌دهنده با فرستادن پیامی به سازمان فرایند CVD را آغاز می‌کند. در این پیام، طرف گزارش‌دهنده توصیف روشنی از آسیب‌پذیری کشف‌شده می‌دهد. عناصر مهم نشانی IP یا URL سامانه آسیب‌دیده و گام‌های لازم برای بازتولید آسیب‌پذیری است.
برای سازمان مهم است که با طرف گزارش‌دهنده روشن ارتباط برقرار کند تا انتظارات درباره فرایند روشن باشد.
سازمان می‌تواند همین حالا با ارسال تأییدیه دریافت (خودکار یا غیر آن) که شامل نشانی از مهلتی است که در آن پاسخ ماهوی اولیه یا بعدی ارسال خواهد شد این کار را انجام دهد.
همچنین ممکن است این دوره باز گذاشته شود و پس از ارزیابی محتوای گزارش نشانی اولیه از مهلت داده شود. توصیه می‌شود هرچه زودتر درباره دوره‌ای که در آن می‌توان به راه‌حل رسید روشن بود. به این ترتیب، گزارش‌دهنده می‌داند چه زمانی می‌توان انتظار نتیجه داشت.
ممکن است در برخی موارد تاریخ انتشار برای طرف گزارش‌دهنده از قبل روشن باشد؛ مثلاً به‌دلیل ارائه در یک همایش یا چون طرف گزارش‌دهنده مهلت خود را تعیین کرده است. در این مورد باز هم مهم است که طرف گزارش‌دهنده این جدول زمانی را به‌روشنی اعلام کند، آن را هرچه زودتر بیان کند و درباره امکان/عدم امکان به تعویق انداختن این تاریخ روشن باشد.
طرف گزارش‌دهنده اغلب فردی بیرون از سازمان است که دیدی از فرایندهای داخلی که یک گزارش می‌تواند آغاز کند ندارد. سازمان‌ها می‌توانند با به‌روزرسانی‌های منظم طرف گزارش‌دهنده را از تحولات فرایند مطلع نگه دارند. این رویکرد برای طرف گزارش‌دهنده روشن می‌کند که روی یک راه‌حل کار می‌شود. در صورت لزوم، سازمان می‌تواند در طول فرایند توضیح بخواهد یا راه‌حل را آزمایش کند.
اگر سازمان نتواند مهلت اولیه حل را رعایت کند، می‌توان درباره به تعویق انداختن آن با گزارش‌دهنده گفت‌وگو کرد. ارتباط منظم می‌تواند این وضعیت را در مرحله زودتری برای گزارش‌دهنده روشن کند.
قصد اصلی CVD کاهش آسیب‌پذیری است، اما «افشای کامل» (full disclosure) آسیب‌پذیری همواره گزینه‌ای برای طرف گزارش‌دهنده است اگر احساس کند فرایند بیش از حد طول می‌کشد. این اقدام همان «چماق بزرگ» (big stick) ضرب‌المثلی است که در اختیار طرف گزارش‌دهنده است. طبیعتاً این وضعیت باید تا حد امکان پیشگیری شود.
ارتباط پس از فرایند افشا
دلایل ممکن بسیاری وجود دارد که چرا یک طرف گزارش‌دهنده ممکن است آسیب‌پذیری‌ها را جست‌وجو کند و سپس از طریق فرایند CVD به سازمان‌ها گزارش دهد. برای شمار زیادی از طرف‌های گزارش‌دهنده، انگیزه مهم قدردانی (علنی) است.
طرف‌های گزارش‌دهنده با سپاس در یک به‌روزرسانی یا ورود به تالار مشاهیر (hall of fame) قدردانی علنی دریافت می‌کنند. با این حال، نیاز به قدردانی علنی برای همه طرف‌های گزارش‌دهنده صدق نمی‌کند؛ برخی در واقع نمی‌خواهند برای عموم شناخته شوند. در صورت ارتباط از سوی سازمان، بنابراین توصیه می‌شود برای ذکر نام طرف گزارش‌دهنده رضایت او گرفته شود.
علاوه بر این، طرف‌های گزارش‌دهنده می‌توانند تصمیم بگیرند پس از پایان فرایند CVD درباره گزارش ارتباط برقرار کنند. برای مثال، طرف گزارش‌دهنده می‌تواند فرایند کشف را شرح دهد یا دیگران را درباره آسیب‌پذیری هشدار دهد. گزارش‌دهنده می‌تواند تصمیم بگیرد انتشار را برای اطلاع به سازمان ارائه کند. از آنجا که فرایند CVD در اصل پس از رفع آسیب‌پذیری پایان می‌یابد، طرف گزارش‌دهنده پس از آن آزاد است درباره آن ارتباط برقرار کند، مگر اینکه توافق‌های اضافی در سیاست یا در طول فرایند انجام شود.
فهرست
ارتباط درباره فرایند افشا
انتشار سیاست CVD در وب‌سایت
روشن‌بودن درباره محدودیت‌ها (برای رویکردهای مختلف فصل ۶ را ببینید)
محدودیت‌ها در روش‌های بررسی
رهنمودهایی درباره ارتباط
رهنمودهایی درباره پاداش‌های ممکن: تالار مشاهیر (Hall of fame)، پاداش مالی، تی‌شرت و غیره
روشن‌بودن درباره هرگونه به‌روزرسانی سیاست CVD، از جمله تاریخ تغییرات
ارتباط در طول فرایند افشا
گزارش‌دهنده درباره آسیب‌پذیری کشف‌شده با سازمان تماس می‌گیرد.
سازمان انتظارات را مدیریت می‌کند، مانند زمان پاسخ برای نخستین پاسخ فنی
سازمان و گزارش‌دهنده درباره دوره حل پیش‌بینی‌شده به یکدیگر وضوح می‌دهند
سازمان مکرراً به‌روزرسانی (فرایند) می‌دهد
در صورت لزوم، گزارش‌دهنده و سازمان درباره تماس با سازمان‌های مرتبط دیگر گفت‌وگو می‌کنند
ارتباط پس از فرایند افشا
گفت‌وگو درباره قدردانی (علنی) و پاداش‌دادن به گزارش‌دهنده
ترتیب‌دادن اینکه اطلاعات درباره آسیب‌پذیری چگونه منتشر شود، مانند مرحله پژوهش یا اطلاع‌رسانی به سازمان‌های دیگر
۶. نمونه‌هایی از سیاست افشای هماهنگ آسیب‌پذیری
شکل‌های مختلف زیادی از متن‌های سیاست درباره افشای هماهنگ آسیب‌پذیری وجود دارد. از آنجا که سیاست CVD منتشرشده نقش تابلوی راهنما برای طرف‌های گزارش‌دهنده بالقوه را دارد، مطمئن شوید شکل این سیاست با سیاست و راهبرد سازمان همسو است.
عناصر زیر در سیاست CVD مهم‌اند:
روش تماس برای ارتباط امن؛
پیش‌شرط‌ها برای طرف‌های گزارش‌دهنده؛
انتظارات روشن برای رسیدگی به گزارش؛
روش پاداش‌دادن به گزارش؛
شماره نسخه و تاریخ آخرین بازنگری.
در زیر سه نمونه آمده است: بسیاری از سازمان‌ها در هلند از نمونه پایه ResponsibleDisclosure.nl الهام گرفته‌اند. سازمان‌های دیگر پیش‌شرط‌های اضافی می‌گنجانند، سیاست Fox IT را ببینید. باز سازمان‌های دیگر قالبی آزادتر برای همسویی با مخاطبان هدف خود به کار می‌برند، سیاست Bits of Freedom را ببینید.
نمونه: ResponsibleDisclosure.nl
این متن را Floor Terra نوشته است و با مجوز Creative Commons Attribution 3.0 Unported منتشر شده است.
در Acme Corporation امنیت سامانه‌های خود را در اولویت اصلی می‌دانیم. اما هرچقدر هم برای امنیت سامانه‌ها تلاش کنیم، باز هم ممکن است آسیب‌پذیری‌هایی وجود داشته باشد.
اگر آسیب‌پذیری‌ای کشف کردید، می‌خواهیم از آن آگاه شویم تا برای رفع آن در سریع‌ترین زمان ممکن اقدام کنیم.
از شما می‌خواهیم به ما کمک کنید از مشتریان و سامانه‌هایمان بهتر محافظت کنیم.
لطفاً کارهای زیر را انجام دهید:
یافته‌های خود را با ایمیل به cert@example.com بفرستید. یافته‌های خود را با کلید PGP ما رمزگذاری کنید تا از افتادن این اطلاعات حیاتی به دست افراد نادرست جلوگیری شود،
از آسیب‌پذیری یا مشکلی که کشف کرده‌اید سوءاستفاده نکنید، مثلاً با دانلود داده بیش از آنچه برای نشان‌دادن آسیب‌پذیری لازم است یا با حذف یا تغییر داده‌های دیگران،
مسئله را تا زمانی که حل نشده برای دیگران فاش نکنید،
از حملات به امنیت فیزیکی، مهندسی اجتماعی، منع سرویس توزیع‌شده، هرزنامه یا برنامه‌های اشخاص ثالث استفاده نکنید، و
اطلاعات کافی برای بازتولید مسئله بدهید تا بتوانیم آن را در سریع‌ترین زمان ممکن حل کنیم. معمولاً نشانی IP یا URL سامانه آسیب‌دیده و شرح آسیب‌پذیری کافی خواهد بود، اما آسیب‌پذیری‌های پیچیده ممکن است به توضیح بیشتر نیاز داشته باشند.
آنچه وعده می‌دهیم:
ظرف ۳ روز کاری با ارزیابی خود از گزارش و تاریخ حل پیش‌بینی‌شده به گزارش شما پاسخ خواهیم داد،
اگر دستورهای بالا را رعایت کرده باشید، در رابطه با گزارش هیچ اقدام حقوقی علیه شما نخواهیم کرد،
گزارش شما را با رازداری کامل رسیدگی خواهیم کرد و اطلاعات شخصی شما را بدون اجازه شما به اشخاص ثالث نخواهیم داد،
شما را از پیشرفت به‌سوی حل مسئله مطلع نگه خواهیم داشت،
در اطلاعات عمومی درباره مسئله گزارش‌شده، نام شما را به‌عنوان کشف‌کننده مسئله ذکر خواهیم کرد (مگر اینکه خلاف آن را بخواهید)، و
به نشانه قدردانی از کمک شما، برای هر گزارش یک مسئله امنیتی که هنوز برای ما شناخته‌شده نبود پاداشی ارائه می‌دهیم. مقدار پاداش بر اساس شدت نشت و کیفیت گزارش تعیین می‌شود. حداقل پاداش یک کارت هدیه ۵۰ یورویی خواهد بود.
می‌کوشیم همه مشکلات را در سریع‌ترین زمان ممکن حل کنیم و می‌خواهیم در انتشار نهایی درباره مسئله پس از حل آن نقش فعالی داشته باشیم.
نمونه: Fox-IT
در Fox-IT امنیت سامانه‌ها، شبکه و محصولات خود را بسیار مهم می‌دانیم. با وجود دقت زیادی که در امنیت به کار می‌بریم، نقاط ضعف همچنان ممکن است باقی بمانند. اگر چنین ضعفی یافته‌اید، دوست داریم هرچه زودتر از آن آگاه شویم تا بتوانیم اقدامات مناسب را هرچه سریع‌تر انجام دهیم.
نقاط ضعف را می‌توان به دو روش کشف کرد: ممکن است هنگام استفاده عادی از یک محیط دیجیتال تصادفاً به چیزی برخورد کنید، یا ممکن است صریحاً تمام تلاش خود را برای یافتن آن‌ها بکنید.
سیاست افشای مسئولانه ما دعوتی برای پویش فعال شبکه کسب‌وکار ما برای کشف نقاط ضعف نیست. ما شبکه کسب‌وکار خود را خودمان پایش می‌کنیم. این یعنی احتمال زیادی وجود دارد که پویشی شناسایی شود و مرکز عملیات امنیت (Security Operation Center، یا SOC) ما بررسی انجام دهد، که ممکن است هزینه‌های غیرضروری در پی داشته باشد. با این حال، از شما دعوت می‌شود آسیب‌پذیری‌ها را در محصولات ما در یک محیط غیرتولیدی آفلاین فعالانه جست‌وجو کنید و یافته‌های خود را به ما گزارش دهید. مسئولیت ما در برابر مشتریان به این معناست که قصد ما تشویق به تلاش برای هک زیرساخت آنان نیست؛ با این حال، می‌خواهیم هرچه زودتر در صورت یافتن آسیب‌پذیری‌ها از شما بشنویم تا بتوانیم آن‌ها را به‌درستی رفع کنیم.
می‌خواهیم با شما همکاری کنیم تا بتوانیم بهتر از مشتریان و سامانه‌هایمان محافظت کنیم.
از شما می‌خواهیم:
یافته‌های خود را هرچه سریع‌تر با ایمیل به security-alert@fox-it.com بفرستید.
از آسیب‌پذیری سوءاستفاده نکنید؛ برای مثال با دانلود، ویرایش یا حذف داده‌ها. ما همیشه گزارش شما را جدی می‌گیریم و هر شک به آسیب‌پذیری را، حتی بدون مدرک، بررسی می‌کنیم.
مسئله را تا زمانی که حل نشده با دیگران در میان نگذارید.
از حملات به امنیت فیزیکی، مهندسی اجتماعی یا ابزارهای هک مانند پویشگرهای آسیب‌پذیری استفاده نکنید.
اطلاعات کافی برای بازتولید مسئله بدهید تا بتوانیم آن را هرچه سریع‌تر حل کنیم. معمولاً نشانی IP یا URL سامانه آسیب‌دیده و شرح آسیب‌پذیری کافی است، هرچند برای آسیب‌پذیری‌های پیچیده‌تر ممکن است اطلاعات بیشتری لازم باشد.
آنچه وعده می‌دهیم:
ظرف سه روز کاری با ارزیابی خود از گزارش و تاریخ حل پیش‌بینی‌شده به گزارش شما پاسخ می‌دهیم.
گزارش شما را محرمانه رسیدگی می‌کنیم و اطلاعات شخصی شما را بدون اجازه شما با اشخاص ثالث در میان نمی‌گذاریم. استثنای این مورد پلیس و قوه قضائیه در صورت تعقیب یا درخواست اطلاعات است.
شما را از پیشرفت حل مسئله مطلع نگه می‌داریم.
در ارتباط درباره مسئله گزارش‌شده، در صورت تمایل شما، نام شما را به‌عنوان طرفی که مسئله را کشف کرده ذکر می‌کنیم.
متأسفانه نمی‌توان از پیش تضمین کرد که علیه شما هیچ اقدام حقوقی انجام نشود. امیدواریم بتوانیم هر وضعیت را جداگانه بررسی کنیم. خود را از نظر اخلاقی موظف می‌دانیم اگر گمان کنیم ضعف یا داده‌ها سوءاستفاده می‌شوند، یا اینکه دانش درباره ضعف را با دیگران در میان گذاشته‌اید، شما را گزارش کنیم. می‌توانید مطمئن باشید که کشف تصادفی در محیط آنلاین ما به تعقیب قضایی نخواهد انجامید.
به‌عنوان سپاس از کمک شما، برای هر گزارش یک مسئله امنیتی که برای ما ناشناخته است پاداشی ارائه می‌دهیم. ارزش پاداش را بر پایه جدیت نقض و کیفیت گزارش تعیین می‌کنیم.
می‌کوشیم همه مشکلات را هرچه سریع‌تر حل کنیم، همه طرف‌های درگیر را مطلع نگه داریم و می‌خواهیم پس از حل مسئله، در هرگونه انتشار درباره آن درگیر باشیم.
نمونه: Bits of Freedom
وابستگی ما به زیرساخت دیجیتال پیوسته در حال افزایش است. این برای جامعه به‌طور کلی صادق است، اما برای خود ما نیز. بنابراین به باور ما دولت‌ها و سازمان‌ها (از جمله سازمان ما) باید قاطعانه به تأمین امنیت زیرساخت دیجیتال خود متعهد شوند. ما می‌دانیم که با وجود بهترین نیت‌ها و بیشترین دقت، ممکن است آسیب‌پذیری‌هایی در سامانه‌های ما وجود داشته باشد. اگر یکی از این ضعف‌ها را یافتید، دوست داریم از شما بشنویم تا بتوانیم مسئله را حل کنیم.
آنچه از شما انتظار داریم
هنگام بررسی یکی از سامانه‌های ما، تناسب حمله را در نظر داشته باشید. لازم نیست نشان دهید که وقتی وب‌سایت ما را در معرض بزرگ‌ترین حمله DDoS تاریخ اینترنت قرار می‌دهید، ممکن است سایت در دسترس نباشد. ما این را می‌دانیم. همچنین می‌فهمیم که اگر با بولدوزر به دفتر ما بزنید، احتمالاً می‌توانید یکی از لپ‌تاپ‌های ما را برباید.
این اصل تناسب هنگام نشان‌دادن خود آسیب‌پذیری نیز مرتبط است. نباید بیش از آنچه کاملاً برای تأیید اعتبار یافته‌تان لازم است داده بررسی یا تغییر دهید. برای مثال، اگر می‌توانید صفحه اصلی ما را تغییر دهید، فقط یک کلمه بی‌حاشیه به آن اضافه کنید به‌جای اینکه کل صفحه را تصاحب کنید. اگر می‌توانید به یک پایگاه داده دسترسی پیدا کنید، کافی است فهرست جدول‌هایی را که در آن هست یا شاید نخستین رکورد یکی از این جدول‌ها را به ما نشان دهید.
آسیب‌پذیری در یکی از سامانه‌های ما باید هرچه زودتر با ایمیل به security@bof.nl گزارش شود. ترجیحاً پیام خود را با OpenPGP رمزگذاری کنید. لطفاً اطلاعات کافی بدهید تا بتوانیم مسئله را بازتولید و بررسی کنیم.
کلید عمومی OpenPGP برای security@bof.nl
تا زمانی که به مسئله رسیدگی نکرده‌ایم و هنوز در چارچوب زمانی معقولی از زمان گزارش شما هستیم، دانش خود درباره آسیب‌پذیری را با طرف‌های دیگر به اشتراک نخواهید گذاشت.
هر اطلاعات محرمانه‌ای را که در طول بررسی خود به دست آورده‌اید به‌محض اینکه آسیب‌پذیری را حل کردیم حذف خواهید کرد.
آنچه می‌توانید از ما انتظار داشته باشید
ظرف سه روز به گزارش شما به‌طور مفصل پاسخ می‌دهیم. برآوردی از زمانی که برای رسیدگی به مسئله نیاز داریم ضمیمه خواهیم کرد. البته شما را از پیشرفت خود به‌طور منظم مطلع خواهیم کرد.
آسیب‌پذیری را هرچه زودتر حل خواهیم کرد. اینجا هم تناسب مهم است: زمان لازم برای رفع آسیب‌پذیری به چند عامل بستگی دارد، از جمله شدت و پیچیدگی مسئله پیش‌رو.
وقتی دستورالعمل‌های بیان‌شده در اینجا را رعایت کنید، در رابطه با گزارش شما علیه شما اقدام حقوقی نخواهیم کرد.
برای ما مهم است که اگر بخواهید از شما برای کاری که کرده‌اید قدردانی کنیم. نام شما را در انتشاری درباره آسیب‌پذیری فقط در صورتی که موافق باشید ذکر خواهیم کرد.
به‌عنوان سپاس از اینکه به محافظت بهتر از سامانه‌هایمان کمک کردید، می‌خواهیم هر گزارش آسیب‌پذیری‌ای را که در آن زمان برای ما ناشناخته بود پاداش دهیم. پاداش به شدت آسیب‌پذیری و کیفیت گزارش بستگی خواهد داشت.
اگر آسیب‌پذیری‌ای در نرم‌افزار شخص ثالثی که استفاده می‌کنیم بیابید و آن آسیب‌پذیری تحت پوشش برنامه bug bounty باشد، ما تلاش نخواهیم کرد آن پاداش را مطالبه کنیم؛ شما باید این کار را بکنید.