Coordinated vulnerability disclosure

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

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

افشای هماهنگ آسیب‌پذیری (Coordinated vulnerability disclosure، به‌اختصار CVD) یک اصطلاح در امنیت رایانه است. این اصطلاح توضیح می‌دهد که افراد چگونه می‌توانند گزارش‌هایی درباره مسائل امنیتی به اشتراک بگذارند. نمونه‌ها عبارت‌اند از گزارش‌های اشکال، خطرهای نفوذ، هشدارهای هک، نشت داده، نفوذ به وب‌سایت‌ها و مانند آن.

ترجمه‌ها: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

فهرست مطالب:

سیاست‌ها:

مقدمه

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

اهداف سند:

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

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

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

از pull request، یا issueهای گیت‌هاب، یا ایمیل به security@joelparkerhenderson.com استقبال می‌کنیم.

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

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

گام‌ها:

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

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

۳. پس از مدتی مشخص، مسئله امنیتی عمومی می‌شود.

گام ۱: مسئله را گزارش کنید

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

  • خوب: کشف‌کننده اطلاعات مربوط را برای تولیدکننده می‌فرستد، مثلاً با ایمیل به نشانی ایمیل امنیتی تولیدکننده (معمولاً «security@example.com») یا از طریق فرم صفحه وب در وب‌سایت تولیدکننده (معمولاً «https://www.example.com/security»).

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

  • نکته: کشف‌کننده می‌تواند ناشناس بماند؛ تولیدکننده نیز می‌تواند ناشناس بماند.

اگر خواستید، همچنان از مسئله آگاه بمانید.

  • خوب: گشودن مسیرهای ارتباطی، یا ارائه اطلاعات پیگیری، یا پایش وضعیت.

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

  • نکته: کشف‌کننده می‌تواند انتخاب کند که کمک کند یا نه، و ارتباط داشته باشد یا نه، و در صورت تغییر شرایط می‌تواند ترتیب را تغییر دهد.

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

  • خوب: صبر برای مدت مشخص‌شده و سپس عمومی‌کردن، مثلاً با انتشار اطلاعات مربوط در یک سایت خبری امنیتی، یا تماس با پژوهشگران امنیتی شخص ثالث مرتبط، یا اعلام مسئله در هر شبکه اجتماعی عمومی و مانند آن.

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

  • نکته: اگر شرایط تغییر کند، مثلاً خطر بالاتر یا بهره‌برداری فعال در دنیای واقعی (in the wild) کشف شود، کشف‌کننده می‌تواند مسئله را زودتر برای دیگران افشا کند.

گام ۲: راه‌های تماس را تضمین کنید

گام ۲ برای تولیدکننده است: مطمئن شوید راه‌های تماس کارآمد هستند.

  • خوب: تولیدکننده یک نشانی ایمیل تماس امنیتی (طبق عرف «security@example.com») و در حالت ایدئال یک کلید رمزگذاری ایمیل امن منتشر می‌کند.

  • خوب: تولیدکننده یک صفحه وب تماس امنیتی (طبق عرف «https://www.example.com/security») منتشر می‌کند و در حالت ایدئال آن را به‌آسانی قابل‌کشف می‌کند، مثلاً از طریق پاورقی وب‌سایت، نقشه سایت و جست‌وجو.

  • بد: تولیدکننده نشانی ایمیل یا صفحه وب ارائه نمی‌دهد، یا آن‌ها را به‌آسانی قابل‌کشف نمی‌کند.

توانایی کارکنان را تضمین کنید.

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

  • خوب: تولیدکننده به‌طور دوره‌ای بررسی می‌کند که توانایی کارکنان کار می‌کند.

  • بد: تولیدکننده آموزش نمی‌دهد یا بررسی نمی‌کند.

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

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

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

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

  • خوب: پاسخ از یک نشانی ایمیل ویژه امنیت، مانند «security@example.com».

  • برای نمونه این‌ها بد هستند: پاسخ از یک نشانی ایمیل عمومی، مانند «help@example.com»، یا از هر کسی که متخصص امنیتی مجاز نیست.

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

  • خوب: عبارت‌های ویژه امنیت، مانند «تیم امنیتی ما گزارش افشای مسئولانه شما را دریافت کرد»، یا «فرایند امنیتی ما این گام‌های بعدی را دارد»، یا «اطلاعات شما اکنون با شماره شناسه XYZ در ردیاب امنیتی ما ثبت است» و مانند آن.

  • بد: عبارت‌های عمومی، مانند «از کسب‌وکار شما قدردانی می‌کنیم»، یا «امنیت را جدی می‌گیریم»، عبارت‌های سرباز‌زدن از مسئولیت مانند «ایمیل شما را به بخش دیگری فرستادیم» و مانند آن.

گام ۳: با حسن نیت کار کنید

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

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

  • هدف شماره ۱ حسن نیت برای کمک به کاربران در محافظت از خود در برابر خطرهای امنیتی است.

  • هدف شماره ۲ حسن نیت برای رسیدگی به مسئله امنیتی است.

  • کشف‌کننده و/یا تولیدکننده می‌توانند با حسن نیت انتخاب کنند که افراد امنیتی دیگری را درگیر کنند، مثلاً با تماس با پژوهشگران امنیتی مرتبط دیگر برای کمک در مسئله.

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

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

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

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

  • افشای هماهنگ آسیب‌پذیری وقتی بهترین است که همه درگیران بدانند هدف شماره ۱ کمک به کاربران برای محافظت از خود در برابر خطرهای امنیتی و هدف شماره ۲ رسیدگی به مسئله امنیتی است.

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

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

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

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

بدانید که معمولاً کشف‌کننده دارد لطفی در حق ناشر می‌کند.

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

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

موفقیت را راستی‌آزمایی کنید

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

  • آیا همه افراد و فرایندها افشا را با موفقیت مدیریت کردند؟ اگر بله، خوب. اگر نه، پژوهش پس از اقدام را در نظر بگیرید، مانند تحلیل علت ریشه‌ای (RCA)، گزارش‌های پس از رویداد (post-mortem)، نمودارهای ایشیکاوا یا تحلیل علّی مبتنی بر نظریه سامانه‌ها (CAST).

  • آیا مسائل باقی‌مانده اولویت‌بندی (triage) شده و پیگیری می‌شوند؟

  • آیا تولیدکننده و کشف‌کننده هر دو می‌دانند برای گام‌های بعدی چه باید کرد؟ درست‌انجام‌دادن این امر به‌ویژه برای حالتی مهم است که ممکن است افشاهای هماهنگ آسیب‌پذیری بعدی در پی باشد.

راهنما

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

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

  • سامری نیکوکار

  • وظیفه نجات

  • وظیفه مراقبت

سامری نیکوکار

Wikipedia: Good Samaritan law

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

وظیفه نجات

Wikipedia: Duty to rescue

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

وظیفه مراقبت

Wikipedia: Duty of care

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

موارد خاص

تیم‌های امنیتی ما طیف گسترده‌ای از موارد خاص را دیده‌اند.

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

دسترسی به اطلاعات کاربران دیگر

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

  • آیا برای کشف‌کننده قابل‌قبول است که این کار را بکند، مثلاً با تنها هدف کشف اینکه آیا کاربران دیگر را هم تحت تأثیر قرار می‌دهد؟

  • آیا درک سریع گستره خطر برای همه کاربران مهم‌تر از محافظت از چند کاربر است که اطلاعاتشان شاید از قبل برای هکرها قابل‌مشاهده باشد؟

  • آیا برای کشف‌کننده قابل‌قبول است که این کار را با هر تعداد کاربر که می‌خواهید انجام دهد؟

  • آیا برای کشف‌کننده قابل‌قبول است که تلاش کند با کاربران تماس بگیرد تا به آن‌ها بگوید تحت تأثیر قرار گرفته‌اند؟ آیا قابل‌قبول است که پیشنهادهایی برای کاهش اثر ارائه دهد؟

منع سرویس

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

  • آیا این حمله منع سرویس به شمار می‌آید؟

ایمیل ناخواسته

مثال: می‌کوشید مسئله‌ای امنیتی را به افرادی در شرکت گزارش دهید که فکر می‌کنید مرتبط‌اند و آن‌ها را با پژوهش در لینکدین، فیس‌بوک و مانند آن، یا با استفاده از قراردادهای نام‌گذاری مانند «webmaster@example.com» یا «security@example.com» پیدا می‌کنید.

  • آیا این قابل‌قبول است؟

  • آیا این ایمیل ناخواسته به شمار می‌آید؟

  • آیا این ایمیل غیرمجاز به شمار می‌آید؟

گروه‌های مستثنا

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

  • آیا برای شما قابل‌قبول است که گزارش دهید؟

  • آیا گزارش‌دادن به‌صورت ناشناس قابل‌قبول است؟

  • آیا تغییر عمدی اطلاعات بالقوه شناسایی‌کننده، مثلاً برای گریز از گروه مستثنا و با هدف کمک به رسیدن افشا به افراد درست، قابل‌قبول است؟

شخص ثالث

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

  • آیا قابل‌قبول است که همه اطلاعاتی را که می‌یابید به هر دو طرف گزارش دهید؟

  • آیا لازم است دو افشای مسئولانه متفاوت انجام شود، مثلاً یک گزارش به یک شرکت و گزارش دیگری به شرکت شخص ثالث، با هدف محدودکردن اطلاعات ارسالی به هر شرکت؟

  • آیا برای کشف‌کننده قابل‌قبول است که شرکت‌ها را با یکدیگر در تماس قرار دهد؟

نرم‌افزار مخرب

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

  • آیا این قابل‌قبول است؟

  • آیا برای کشف‌کننده قابل‌قبول است که کاربران را به نرم‌افزاری مانند این و/یا به راهنماها یا آموزش‌هایی که شرح می‌دهند چگونه این نوع نرم‌افزار ساخته می‌شود ارجاع دهد؟

افشای هماهنگ آسیب‌پذیری در برابر افشای مسئولانه

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

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

افشای مسئولانه (responsible disclosure) اصطلاحی منسوخ است.

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

پیگیری