Coordinated vulnerability disclosure

Pengungkapan kerentanan terkoordinasi (CVD)

Cara melaporkan, menerima, dan mengoordinasikan kerentanan keamanan, dengan contoh kebijakan.

Pengungkapan kerentanan terkoordinasi (Coordinated vulnerability disclosure, CVD) adalah istilah keamanan komputer. Istilah ini menjelaskan bagaimana orang dapat membagikan laporan tentang masalah keamanan. Contohnya adalah laporan bug, risiko penyusupan, peringatan peretasan, kebocoran data, pembobolan situs web, dan sebagainya.

Terjemahan: العربية, Български, বাংলা, Č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, 中文

Daftar isi:

Kebijakan:

Pendahuluan

Dokumen ini menjelaskan pengungkapan kerentanan terkoordinasi dengan cara yang dapat membantu orang bekerja sama.

Tujuan dokumen:

  1. Membantu orang yang menemukan masalah keamanan dan ingin melaporkannya.

  2. Membantu perwakilan perusahaan memahami kebutuhan, tujuan, praktik, dan kasus khusus pengungkapan yang bertanggung jawab.

  3. Menyertakan contoh kebijakan pengungkapan kerentanan terkoordinasi di folder repositori.

Kami menyambut pull request, atau isu GitHub, atau email ke security@joelparkerhenderson.com.

Apa itu pengungkapan kerentanan terkoordinasi?

Pengungkapan kerentanan terkoordinasi menjelaskan tiga langkah ketika seseorang menemukan masalah keamanan (seperti bug perangkat lunak) dan ingin melaporkannya kepada produsen (seperti perusahaan yang membuat perangkat lunak tersebut).

Langkah-langkah:

  1. Penemu melaporkan masalah secara pribadi dengan itikad baik kepada produsen.

  2. Produsen berusaha melindungi pengguna dengan itikad baik dan berusaha mengatasi masalah tersebut.

  3. Setelah jangka waktu tertentu, masalah keamanan tersebut diumumkan kepada publik.

Langkah 1: Laporkan masalahnya

Langkah 1 adalah untuk penemu: laporkan masalah secara pribadi dengan itikad baik.

  • Baik: Penemu mengirimkan informasi yang relevan kepada produsen, misalnya melalui email ke alamat email keamanan produsen (biasanya "security@example.com") atau melalui formulir halaman web di situs web produsen (biasanya "https://www.example.com/security").

  • Buruk: memposting laporan di blog publik, atau memberi tahu media, atau mengancam, atau mencoba menjual masalah keamanan kepada peretas, dan sebagainya.

  • Tips: penemu boleh memilih untuk anonim; produsen juga boleh memilih untuk anonim.

Jika Anda mau, tetaplah mengikuti perkembangan masalah tersebut.

  • Baik: membuka jalur komunikasi, atau memberikan informasi tindak lanjut, atau memantau situasi.

  • Buruk: melupakan masalah tersebut.

  • Tips: penemu boleh memilih untuk membantu atau tidak, dan juga boleh memilih untuk berkomunikasi atau tidak, dan juga boleh mengubah pengaturan jika keadaan berubah.

Jika Anda mau, ungkapkan masalah tersebut kepada pihak lain.

  • Baik: menunggu jangka waktu yang ditentukan lalu mengumumkannya ke publik, misalnya memposting informasi yang relevan ke situs berita keamanan, atau menghubungi peneliti keamanan pihak ketiga yang relevan, atau mengumumkan masalah tersebut di media sosial publik mana pun, dan sebagainya.

  • Buruk: tidak mengungkapkan masalah kepada pihak lain, kecuali jika Anda merasa hal itu akan menimbulkan risiko yang lebih besar bagi diri Anda atau orang lain.

  • Tips: jika keadaan berubah, misalnya ditemukan risiko yang lebih tinggi atau eksploitasi aktif di dunia nyata, maka penemu dapat mengungkapkan masalah tersebut kepada pihak lain lebih cepat.

Langkah 2: Pastikan kontak tersedia

Langkah 2 adalah untuk produsen: pastikan kontak dapat digunakan.

  • Baik: Produsen menerbitkan alamat email kontak keamanan (lazimnya "security@example.com") dan idealnya kunci enkripsi email yang aman.

  • Baik: Produsen menerbitkan halaman web kontak keamanan (lazimnya "https://www.example.com/security") dan idealnya membuat halaman tersebut mudah ditemukan, misalnya melalui footer situs web, peta situs, dan pencarian.

  • Buruk: Produsen tidak menyediakan alamat email atau halaman web, atau tidak membuatnya mudah ditemukan.

Pastikan kemampuan staf.

  • Baik: Produsen melatih staf dukungan tentang apa yang harus dilakukan jika menerima pertanyaan keamanan, misalnya cara menanggapi dengan informasi kontak, atau cara meneruskan pertanyaan tersebut ke tim internal yang tepat.

  • Baik: Produsen secara berkala memverifikasi bahwa kemampuan staf berfungsi.

  • Buruk: Produsen tidak melatih atau tidak memverifikasi.

Tanggapi penemu sesuai jangka waktu yang ditentukan.

  • Jika penemu tidak menentukan jangka waktu, gunakan satu hari kerja, karena ini adalah standar industri dan praktik terbaik industri saat ini.

  • Jika penemu mengajukan pertanyaan, jawablah. Hal ini sangat penting jika penemu meminta izin untuk menguji. Pastikan semua jawaban jelas dan langsung.

Tanggapi penemu melalui kontak keamanan yang berwenang dan/atau proses keamanan yang berwenang.

  • Baik: tanggapan dari alamat email khusus keamanan, seperti "security@example.com".

  • Contohnya ini buruk: tanggapan dari alamat email umum, seperti "help@example.com", atau dari siapa pun yang bukan profesional keamanan yang berwenang.

Beri tahu penemu bahwa masalah tersebut diakui sebagai laporan keamanan.

  • Baik: kata-kata khusus keamanan, seperti "Tim keamanan kami telah menerima laporan pengungkapan yang bertanggung jawab dari Anda", atau "Proses keamanan kami memiliki langkah-langkah berikutnya ini", atau "Informasi Anda kini ada di pelacak keamanan kami dengan nomor id XYZ", dan sebagainya.

  • Buruk: kata-kata umum, seperti "Kami menghargai bisnis Anda", atau "Kami menganggap serius keamanan", kata-kata yang melempar tanggung jawab seperti "Kami telah meneruskan email Anda ke departemen lain", dan sebagainya.

Langkah 3: Bekerja dengan itikad baik

Langkah 3 adalah untuk penemu dan produsen bersama-sama: bekerja dengan itikad baik.

Pahami bahwa pengungkapan kerentanan terkoordinasi menggambarkan proses yang berlandaskan itikad baik.

  • Tujuan nomor 1 adalah itikad baik untuk membantu pengguna melindungi diri dari risiko keamanan.

  • Tujuan nomor 2 adalah itikad baik untuk mengatasi masalah keamanan.

  • Penemu dan/atau produsen boleh memilih dengan itikad baik untuk melibatkan orang keamanan lainnya, misalnya menghubungi peneliti keamanan lain yang relevan untuk membantu menangani masalah tersebut.

Pahami bahwa pengungkapan kerentanan terkoordinasi tidak menciptakan kewajiban apa pun.

  • Penemu dan/atau produsen boleh keluar kapan saja, dengan alasan apa pun, dengan atau tanpa peringatan. Sopan santun menuntut agar semua orang terkait tetap diberi tahu dan mendapat informasi terbaru, tetapi hal ini tidak selalu mungkin, praktis, atau diinginkan.

  • Pengungkapan kerentanan terkoordinasi tidak menciptakan perjanjian hukum apa pun. Jika penemu dan produsen sudah memiliki perjanjian hukum, maka kami menyarankan agar semua pihak terkait berkonsultasi dengan pengacara yang tepat; jangan gunakan dokumen ini sebagai nasihat hukum.

Pahami bahwa pengungkapan kerentanan terkoordinasi bertujuan menggunakan komunikasi yang baik dan bertujuan menolak ancaman.

  • Pengungkapan kerentanan terkoordinasi paling baik jika semua pihak terkait memahami bahwa tujuan nomor 1 adalah membantu pengguna melindungi diri dari risiko keamanan, dan tujuan nomor 2 adalah mengatasi masalah keamanan.

  • Pengungkapan kerentanan terkoordinasi menolak segala bentuk ancaman pembalasan, intimidasi, penangguhan, pencabutan, pemerasan, beban untuk menindaklanjuti, atau menyalahkan korban.

Pahami bahwa pengungkapan kerentanan terkoordinasi dapat memiliki arti yang berbeda bagi orang yang berbeda.

  • Penemu dan produsen mungkin memiliki pemahaman yang berbeda tentang pengungkapan kerentanan terkoordinasi. Pemahaman ini mungkin tidak selaras satu sama lain. Itikad baik mencakup kesediaan semua pihak terkait untuk memahami hal ini.

  • Beberapa produsen menerbitkan kebijakan pengungkapan kerentanan terkoordinasi. Kebijakan ini dapat menjadi panduan yang bermanfaat. Jika penemu memilih menggunakan jenis pengungkapan kerentanan terkoordinasi yang berbeda, atau memiliki pemahaman yang berbeda tentang pengungkapan yang bertanggung jawab, hal itu sama sekali tidak masalah.

Pahami bahwa biasanya penemu sedang memberikan bantuan kepada penerbit.

  • Biasanya penemu tidak memerlukan izin siapa pun untuk menerbitkan kerentanan.

  • Biasanya informasi dari penemu membantu penerbit.

Verifikasi keberhasilan

Setelah masalah terselesaikan, produsen harus memverifikasi keberhasilan.

  • Apakah semua orang dan proses menangani pengungkapan dengan berhasil? Jika ya, bagus. Jika tidak, pertimbangkan untuk melakukan penelitian pascatindakan, seperti analisis akar masalah (RCA), laporan post-mortem, diagram Ishikawa, atau analisis kausal berbasis teori sistem (CAST).

  • Apakah masalah yang masih tersisa sudah dipilah (triage) dan dilacak?

  • Apakah produsen dan penemu sama-sama memahami apa yang harus dilakukan untuk langkah selanjutnya? Hal ini sangat penting untuk dilakukan dengan benar jika mungkin ada pengungkapan kerentanan terkoordinasi lanjutan.

Panduan

Panduan untuk pengungkapan kerentanan terkoordinasi dapat berasal dari banyak bidang, seperti pakar etika, advokat hukum, ekspektasi wajar masyarakat umum, dan sebagainya.

Jika Anda mencari panduan, maka Anda mungkin tertarik dengan tiga bidang ini, yang semuanya dijelaskan di bawah.

  • Orang Samaria yang baik

  • Kewajiban menolong

  • Kewajiban kehati-hatian

Orang Samaria yang baik

Wikipedia: Good Samaritan law

Hukum Orang Samaria yang baik memberikan perlindungan hukum kepada orang yang memberikan bantuan yang wajar kepada mereka yang terluka, sakit, dalam bahaya, atau tidak berdaya, atau yang mereka yakini demikian. Perlindungan ini dimaksudkan untuk mengurangi keraguan orang di sekitar untuk membantu, karena takut digugat atau dituntut.

Kewajiban menolong

Wikipedia: Duty to rescue

Kewajiban menolong adalah konsep yang menggambarkan keadaan ketika suatu pihak dapat dimintai pertanggungjawaban karena tidak menolong pihak lain yang berada dalam bahaya. Kewajiban menolong dapat memiliki aspek moral dan/atau aspek hukum.

Kewajiban kehati-hatian

Wikipedia: Duty of care

Kewajiban kehati-hatian adalah kewajiban untuk memenuhi standar kehati-hatian yang wajar saat melakukan tindakan apa pun yang dapat diperkirakan merugikan orang lain. Kewajiban kehati-hatian dapat memiliki aspek moral dan/atau aspek hukum. Beberapa aspek yang perlu dipertimbangkan adalah: dapat diperkirakannya kerugian atau cedera, besarnya kemungkinan kerugian atau cedera yang berpotensi terjadi, pentingnya atau nilai sosial dari kegiatan yang dilakukan oleh tergugat, kegunaan perilaku tersebut bagi tergugat, kelayakan perilaku alternatif, biaya dan beban yang terkait dengan perilaku alternatif, kegunaan relatif dari perilaku alternatif, dan keamanan relatif dari perilaku alternatif.

Kasus khusus

Tim keamanan kami telah melihat beragam kasus khusus.

Kami menjelaskannya di sini untuk membantu orang memahami di mana terdapat beragam pendapat tentang apa yang mungkin boleh dan apa yang mungkin tidak boleh. Kami menyarankan agar semua pihak terkait berkomunikasi dengan itikad baik tentang hal-hal ini.

Mengakses informasi pengguna lain

Contoh: Anda menemukan bahwa sebuah URL memuat id pengguna Anda, dan memperlihatkan sebuah bug, dan Anda yakin dapat mengedit URL untuk mengubah id pengguna Anda menjadi id pengguna yang berbeda.

  • Apakah boleh bagi penemu untuk melakukan ini, misalnya dengan satu-satunya tujuan untuk mengetahui apakah hal ini juga memengaruhi pengguna lain?

  • Apakah lebih penting untuk segera memahami luasnya risiko bagi semua pengguna, daripada melindungi beberapa pengguna yang informasinya mungkin sudah terlihat oleh peretas?

  • Apakah boleh bagi penemu melakukannya terhadap sebanyak mungkin pengguna yang Anda inginkan?

  • Apakah boleh bagi penemu mencoba menghubungi pengguna untuk memberi tahu bahwa mereka terdampak? Apakah boleh menawarkan saran mitigasi?

Penolakan layanan

Contoh: Anda menemukan bug yang secara tidak sengaja menangguhkan akun Anda, misalnya memicu penguncian kata sandi.

  • Apakah ini dianggap sebagai serangan penolakan layanan?

Email yang tidak diminta

Contoh: Anda mencoba melaporkan masalah keamanan kepada orang-orang di perusahaan yang menurut Anda relevan, dan yang Anda temukan melalui riset di LinkedIn, Facebook, dan sebagainya, atau dengan menggunakan konvensi penamaan seperti "webmaster@example.com" atau "security@example.com".

  • Apakah ini boleh?

  • Apakah ini dianggap sebagai email yang tidak diminta?

  • Apakah ini dianggap sebagai email yang tidak sah?

Kelompok yang dikecualikan

Contoh: Anda berada dalam kelompok yang dikecualikan, seperti masih di bawah umur, atau berada dalam daftar sanksi, atau berada di negara yang masuk daftar sanksi.

  • Apakah boleh bagi Anda membuat laporan?

  • Apakah boleh melapor secara anonim?

  • Apakah boleh dengan sengaja mengubah informasi yang berpotensi mengidentifikasi, misalnya untuk keluar dari kelompok yang dikecualikan, dan dengan tujuan membantu pengungkapan sampai kepada orang yang tepat?

Pihak ketiga

Contoh: Anda menemukan bahwa perangkat lunak sebuah perusahaan memiliki bug yang melibatkan pihak ketiga, seperti integrasi dengan perangkat lunak lain atau situs web lain.

  • Apakah boleh bagi Anda melaporkan semua informasi yang Anda temukan kepada kedua pihak?

  • Apakah perlu melakukan dua pengungkapan yang bertanggung jawab yang berbeda, misalnya satu laporan untuk satu perusahaan, dan laporan yang berbeda untuk perusahaan pihak ketiga, dengan tujuan membatasi informasi yang dikirim ke setiap perusahaan?

  • Apakah boleh bagi penemu mempertemukan perusahaan-perusahaan tersebut satu sama lain?

Perangkat lunak yang mengganggu

Contoh: Anda cukup mahir untuk dapat menulis virus yang menurut Anda kemungkinan besar akan membantu pengguna melindungi diri dari risiko keamanan, atau mengetahui apakah mereka berisiko, atau memperbaiki risiko keamanan tersebut.

  • Apakah ini boleh?

  • Apakah boleh bagi penemu mengarahkan pengguna ke perangkat lunak semacam ini, dan/atau ke panduan atau tutorial yang menjelaskan cara membuat perangkat lunak semacam ini?

Pengungkapan kerentanan terkoordinasi vs. pengungkapan yang bertanggung jawab

Pengungkapan kerentanan terkoordinasi adalah istilah yang lebih disukai.

  • Aspek terpenting adalah koordinasi antara penemu dan produsen.

Pengungkapan yang bertanggung jawab (responsible disclosure) adalah istilah yang sudah tidak dianjurkan.

  • Orang memiliki pandangan yang berbeda tentang apa artinya bertanggung jawab. Misalnya, beberapa orang berpendapat bahwa penemu bertanggung jawab untuk segera memberi tahu publik tanpa memandang interaksi apa pun dengan produsen, dan tidak bertanggung jawab jika melakukan pengungkapan kerentanan terkoordinasi karena hal itu menyembunyikan informasi dari publik.

Pelacakan