it-swarm-id.com

Bagaimana cara mengungkapkan kerentanan keamanan secara etis?

Bagaimana cara mengungkapkan kerentanan keamanan dengan cara yang etis? Saya pernah mendengar ada berbagai aliran pemikiran tentang topik ini. Saya ingin mengetahui pro/kontra dari masing-masing.

75
Olivier Lalonde

Anda harus memberi tahu pengembang secara pribadi sehingga mereka memiliki kesempatan untuk memperbaikinya. Setelah itu, jika dan ketika Anda go public dengan kerentanan, Anda harus memberikan waktu yang cukup bagi pengembang untuk memperbaiki masalah dan siapa pun yang terpapar cukup waktu untuk meningkatkan sistem mereka. Secara pribadi, saya akan mengizinkan pengembang untuk membuat pengumuman di buletin keamanan dalam banyak kasus daripada mengumumkannya sendiri. Paling tidak, saya akan menunggu konfirmasi bahwa kerentanan telah diperbaiki. Jika Anda punya waktu dan memiliki akses ke kode sumber, Anda juga bisa memberikan tambalan.

43
VirtuosiMedia

Secara pribadi saya pikir Pengungkapan yang bertanggung jawab tampaknya menjadi cara terbaik untuk pergi dari titik etika dan bekerja dengan baik untuk Dan Kaminsky mengungkapkan rincian kerentanan keracunan cache DNS. Tapi itu semua sangat tergantung pada perusahaan atau grup yang Anda hadapi dan juga basis pengguna yang akan terpengaruh.

27
Mark Davidson

@VirtuosiMedia melakukan pekerjaan yang baik untuk menguraikan "Pengungkapan Bertanggung Jawab".

Saya akan menambahkan dua poin:

  • Bekerja dengan vendor (jika Anda bisa), untuk memastikan mereka memahaminya sepenuhnya dan tidak mengeluarkan tambalan setengah matang.
  • Jika vendor mengabaikan Anda atau mengabaikan Anda, teruslah berusaha. Namun, jika mereka mengklaim itu bukan kerentanan, silakan dan publikasikan. Sekeras mungkin. Jika mereka berjanji untuk memperbaiki, tetapi tidak, cobalah untuk mendapatkan jawaban dari mereka, bersama dengan garis waktu yang pasti yang mereka komit. Pada titik tertentu, jika mereka terus menunda, pada akhirnya Anda mungkin ingin memberi tahu mereka bahwa Anda akan menerbitkannya - dan kemudian memberi mereka waktu untuk memperbaikinya (tetapi singkat dan terbatas.)
18
AviD

Ini adalah salah satu dari topik yang rumit. Saya terlibat dalam pengungkapan bug negosiasi ulang TLS beberapa tahun yang lalu, dan percayalah, kami berusaha sangat keras untuk menjadi "bertanggung jawab", tetapi pada akhirnya, kami berhasil terutama membuat marah semua orang di sekitar kami dan (mungkin) menunda rilis perbaikan yang sebenarnya. Bukan untuk mengatakan bahwa pemberitahuan vendor selalu buruk, hanya saja sangat mudah untuk mendapatkan whipsaw dan akhirnya menyebabkan banyak kerusakan baik, atau lebih buruk.

Dalam kasus kami, dibutuhkan tindakan IETF ( RFC 5746 ) untuk menyelesaikan masalah, dan meskipun kami memiliki draf internet yang siap pada hari bocor, pekerjaan sebenarnya dari berdebat dan memutuskan solusi membutuhkan waktu sekitar tiga bulan lagi, dan tidak benar-benar memulai dengan sungguh-sungguh sampai pengungkapannya terjadi.

Ngomong-ngomong, ini bukan jawaban untuk pertanyaan Anda, tapi itu salah satu kisah pengungkapan yang lebih menarik yang saya ketahui. Lebih banyak tentang kisah itu di keynote ShmooCon 201 Saya lakukan dengan Marsh Ray, yang menemukan masalah.

11
Steve Dispensa

Secara umum, itu tergantung pada respon vendor. Praktik yang baik adalah ketika peneliti keamanan menginformasikan vendor tentang kerentanan, maka selama percakapan Anda berbicara tentang ketentuan publikasi poc/mengeksploitasi kerentanan ini. Sebenarnya, peneliti memilih apa yang harus dilakukan dengan kerentanan ini - dipublikasikan nanti atau tidak. Kemudian vendor merilis versi patch atau produk baru. Mungkin. Tapi, bagaimana pengalaman menunjukkan - tidak semua vendor begitu baik. Beberapa dari mereka memperbaiki bug secara diam-diam, tanpa memberi tahu pengguna akhir dan peneliti, beberapa lebih suka mengabaikan peneliti. Yang lain bahkan mencoba menuntut. Itulah sebabnya terkadang anonimitas lebih disukai sebagai cara komunikasi awal dengan vendor yang tidak dikenal.

Saya juga ingin mengakui bahwa ada program hadiah bug bug - yang ditawarkan oleh Google, Mozilla. Selain itu, yang lain membeli kerentanan - ZDI , iDefense , SNOsoft , datang "exploit hub", dan dll. Jadi, setidaknya ada tiga cara bagaimana menginformasikan vendor - secara langsung, dengan menerbitkan informasi kerentanan pada beberapa daftar atau melalui perusahaan pihak ketiga.

8
anonymous

Jika mereka memiliki pelacak masalah publik, lihat apakah Anda dapat mengajukan bug dengan label "pribadi" atau "keamanan".

Terlepas dari apakah mereka memiliki pelacak masalah, email [email protected] nama perusahaan dan beri tahu mereka.

Jika mereka tidak merespons dengan cukup cepat (lihat "Window of Disclosure" dalam artikel Schneier di bawah), maka Anda perlu memikirkan untuk mengungkapkannya secara lebih luas. Cari milis yang mengintai akademisi/profesional keamanan dan tanyakan kepada mereka bagaimana mereka melaporkan masalah kepada vendor yang dimaksud. Mereka mungkin dapat memperkenalkan tempat yang tepat di organisasi.

Jika semua itu gagal, baca bit Schneier dan pikirkan apakah pengungkapan penuh akan menjadi bagian dari masalah atau bagian dari solusi.

Bruce Schneier memberikan argumen untuk pengungkapan penuh dalam keadaan tertentu berdasarkan pada "menjadi bagian dari solusi, bukan bagian dari masalah" standar. Ini pasti layak dibaca.

Ini adalah perdebatan klasik "kerahasiaan bug vs. pengungkapan penuh". Saya sudah menulis tentang itu sebelumnya di Crypto-Gram; yang lain telah menulis tentang itu juga. Ini adalah masalah yang rumit dengan implikasi halus di seluruh keamanan komputer, dan layak untuk dibahas lagi.

...

Aliran informasi gratis ini, baik dari deskripsi maupun kode bukti-konsep, juga penting untuk penelitian keamanan. Penelitian dan pengembangan dalam keamanan komputer telah berkembang dalam dekade terakhir, dan banyak dari itu dapat dikaitkan dengan gerakan pengungkapan penuh. Kemampuan untuk mempublikasikan temuan penelitian - baik dan buruk - mengarah pada keamanan yang lebih baik untuk semua orang. Tanpa publikasi, komunitas keamanan tidak dapat saling belajar dari kesalahan satu sama lain. Setiap orang harus beroperasi dengan penutup mata, membuat kesalahan yang sama berulang kali. Pengungkapan penuh sangat penting jika kita ingin terus meningkatkan keamanan komputer dan jaringan kita.

...

Kedua, saya percaya memberikan pemberitahuan terlebih dahulu kepada vendor. CERT mengambil ini ke ekstrim, kadang-kadang memberi vendor tahun untuk memperbaiki masalah.

...

Saya suka metrik "menjadi bagian dari solusi, bukan bagian dari masalah". Meneliti keamanan adalah bagian dari solusi. Meyakinkan vendor untuk memperbaiki masalah adalah bagian dari solusi. Menabur ketakutan adalah bagian dari masalah. Menyerahkan alat serangan kepada remaja yang tidak mengerti adalah bagian dari masalah.

6
Mike Samuel