Pengungkapan Penuh atau Bertanggung Jawab: Bagaimana Pengungkapan Kerentanan Keamanan

Iklan

Tiga minggu yang lalu, masalah keamanan yang serius di OS X 10.10.4 ditemukan. Itu, dalam dirinya sendiri, tidak terlalu menarik.

Kerentanan keamanan dalam paket perangkat lunak populer ditemukan sepanjang waktu, dan OS X tidak terkecuali. Basis Data Kerentanan Open Source (OSVDB) menunjukkan setidaknya 1.100 kerentanan ditandai sebagai "OS X". Tapi apa adalah menarik adalah cara di mana kerentanan khusus ini diungkapkan.

Daripada memberi tahu Apple dan memberi mereka waktu untuk memperbaiki masalah, peneliti memutuskan untuk memposting eksploitinya di Internet untuk dilihat semua orang.

Hasil akhirnya adalah perlombaan senjata antara Apple dan peretas topi hitam. Apple harus merilis tambalan sebelum kerentanan dipersenjatai, dan para peretas harus membuat eksploit sebelum sistem yang berisiko ditambal.

Anda mungkin berpikir bahwa metode pengungkapan tertentu tidak bertanggung jawab. Anda bahkan bisa menyebutnya tidak etis, atau ceroboh. Tapi ini lebih rumit dari itu. Selamat datang di dunia pengungkapan kerentanan yang aneh dan membingungkan.

Pengungkapan Penuh vs Bertanggung Jawab

Ada dua cara populer untuk mengungkapkan kerentanan terhadap vendor perangkat lunak.

Yang pertama disebut pengungkapan penuh. Sama seperti pada contoh sebelumnya, para peneliti segera mempublikasikan kerentanan mereka ke alam bebas, sehingga vendor sama sekali tidak memiliki kesempatan untuk merilis perbaikan.

Yang kedua disebut pengungkapan yang bertanggung jawab, atau pengungkapan terhuyung-huyung. Di sinilah peneliti menghubungi vendor sebelum kerentanan dirilis.

Kedua belah pihak kemudian menyepakati kerangka waktu di mana peneliti berjanji untuk tidak mempublikasikan kerentanan, untuk memberikan vendor kesempatan untuk membangun dan merilis perbaikan. Periode waktu ini bisa di mana saja dari 30 hari hingga satu tahun, tergantung pada tingkat keparahan dan kompleksitas kerentanan. Beberapa lubang keamanan tidak dapat diperbaiki dengan mudah, dan mengharuskan seluruh sistem perangkat lunak dibangun kembali dari awal.

Setelah kedua belah pihak puas dengan perbaikan yang telah dihasilkan, kerentanan kemudian diungkapkan dan diberikan a Nomor CVE. Ini secara unik mengidentifikasi setiap kerentanan, dan kerentanan tersebut diarsipkan secara online di OSVDB.

Tetapi apa yang terjadi jika waktu tunggu berakhir? Nah, satu dari dua hal. Vendor kemudian akan menegosiasikan ekstensi dengan peneliti. Tetapi jika peneliti tidak puas dengan bagaimana vendor merespons atau berperilaku, atau mereka merasa permintaan untuk perpanjangan tidak masuk akal, mereka mungkin hanya mempublikasikannya secara online tanpa perbaikan siap.

Di bidang keamanan, ada perdebatan sengit tentang metode pengungkapan apa yang terbaik. Beberapa orang berpikir bahwa satu-satunya metode etis dan akurat adalah pengungkapan penuh. Beberapa orang berpikir bahwa yang terbaik adalah memberi vendor kesempatan untuk memperbaiki masalah sebelum melepaskannya ke alam liar.

Ternyata, ada beberapa argumen kuat untuk kedua belah pihak.

Argumen Yang Mendukung Pengungkapan Yang Bertanggung Jawab

Mari kita lihat contoh di mana cara terbaik untuk menggunakan pengungkapan yang bertanggung jawab.

Ketika kita berbicara tentang infrastruktur kritis dalam konteks Internet, sulit untuk dihindari protokol DNS Cara Mengubah Server DNS Anda & Meningkatkan Keamanan InternetBayangkan ini - Anda bangun suatu pagi yang indah, tuangkan secangkir kopi untuk diri sendiri, dan kemudian duduk di depan komputer Anda untuk memulai pekerjaan Anda untuk hari itu. Sebelum Anda benar-benar mendapatkan ... Baca lebih banyak . Inilah yang memungkinkan kami untuk menerjemahkan alamat web yang dapat dibaca manusia (seperti makeuseof.com) menjadi alamat IP.

Sistem DNS sangat rumit, dan tidak hanya pada tingkat teknis. Ada banyak kepercayaan yang ditempatkan dalam sistem ini. Kami percaya bahwa ketika kami mengetikkan alamat web, kami dikirim ke tempat yang tepat. Cukup banyak yang mengandalkan integritas sistem ini.

Jika seseorang dapat mengganggu, atau kompromi permintaan DNS, ada banyak potensi kerusakan. Misalnya, mereka dapat mengirim orang ke halaman perbankan online palsu, sehingga memungkinkan mereka untuk mendapatkan rincian perbankan online mereka. Mereka dapat mencegat lalu lintas email dan daring mereka melalui serangan orang di tengah, dan membaca isinya. Mereka secara fundamental dapat merusak keamanan Internet secara keseluruhan. Barang yang mengerikan.

Dan Kaminsky adalah peneliti keamanan yang sangat dihormati, dengan resume panjang menemukan kerentanan dalam perangkat lunak terkenal. Tapi dia paling terkenal karena penemuan 2008 mungkin kerentanan paling parah dalam sistem DNS yang pernah ditemukan. Ini akan memungkinkan seseorang untuk dengan mudah melakukan cache poisoning (atau DNS spoofing) menyerang server nama DNS. Rincian yang lebih teknis dari kerentanan ini dijelaskan pada konferensi Def Con 2008.

Kaminsky, yang benar-benar sadar akan konsekuensi dari melepaskan cacat yang sedemikian parah, memutuskan untuk mengungkapkannya kepada vendor perangkat lunak DNS yang terpengaruh oleh bug ini.

Ada sejumlah produk DNS utama yang terpengaruh, termasuk yang dibangun oleh Alcatel-Lucent, BlueCoat Technologies, Apple dan Cisco. Masalah ini juga memengaruhi sejumlah implementasi DNS yang dikirimkan dengan beberapa distribusi Linux / BSD yang populer, termasuk untuk Debian, Arch, Gentoo, dan FreeBSD.

Kaminsky memberi mereka 150 hari untuk menghasilkan perbaikan, dan bekerja bersama mereka secara rahasia untuk membantu mereka memahami kerentanan. Dia tahu bahwa masalah ini sangat parah, dan potensi kerusakannya sangat besar, sehingga bisa terjadi sangat ceroboh untuk merilisnya secara publik tanpa memberikan vendor kesempatan untuk mengeluarkan a tambalan.

Kebetulan, kerentanan itu bocor secara tidak sengaja oleh perusahaan keamanan Matsano dalam sebuah posting blog. Artikel itu dihapus, tetapi dicerminkan, dan satu hari setelah publikasi eksploitasi Inilah Cara Mereka Meretas Anda: Dunia Keruh Kit EksploitasiScammers dapat menggunakan suite perangkat lunak untuk mengeksploitasi kerentanan dan membuat malware. Tapi apa ini kit exploit? Mereka berasal dari mana? Dan bagaimana mereka bisa dihentikan? Baca lebih banyak telah dibuat.

Kerentanan DNS Kaminsky pada akhirnya meringkaskan inti dari argumen yang mendukung pengungkapan yang bertanggung jawab dan terhuyung-huyung. Beberapa kerentanan - seperti kerentanan nol hari Apa itu Kerentanan Hari Nol? [MakeUseOf Menjelaskan] Baca lebih banyak - sangat signifikan, sehingga melepaskannya secara publik akan menyebabkan kerusakan yang signifikan.

Tetapi ada juga argumen kuat yang mendukung tidak memberikan peringatan terlebih dahulu.

Kasing Untuk Pengungkapan Penuh

Dengan melepaskan kerentanan ke tempat terbuka, Anda membuka kunci kotak pandora di mana individu yang jahat dapat dengan cepat dan mudah menghasilkan eksploitasi, dan membahayakan sistem yang rentan. Jadi, mengapa seseorang memilih untuk melakukan itu?

Ada beberapa alasan. Pertama, vendor seringkali cukup lambat untuk menanggapi pemberitahuan keamanan. Dengan secara efektif memaksa tangan mereka dengan melepaskan kerentanan ke alam liar, mereka lebih termotivasi untuk merespons dengan cepat. Lebih buruk lagi, beberapa cenderung untuk tidak mempublikasikan Mengapa Perusahaan Menjaga Pelanggaran Rahasia bisa menjadi Hal yang BaikDengan begitu banyak informasi online, kita semua khawatir tentang kemungkinan pelanggaran keamanan. Tapi pelanggaran ini bisa dirahasiakan di AS untuk melindungi Anda. Kedengarannya gila, jadi apa yang terjadi? Baca lebih banyak fakta bahwa mereka mengirim perangkat lunak yang rentan. Pengungkapan penuh memaksa mereka untuk jujur ​​dengan pelanggan mereka.

Tetapi ini juga memungkinkan konsumen untuk membuat pilihan berdasarkan informasi apakah mereka ingin terus menggunakan perangkat lunak yang rentan. Saya akan membayangkan mayoritas tidak akan melakukannya.

Apa yang Vendor Inginkan?

Vendor sangat tidak suka pengungkapan penuh.

Lagipula, itu PR yang sangat buruk bagi mereka, dan itu menempatkan pelanggan mereka dalam risiko. Mereka telah mencoba memberi insentif kepada orang-orang untuk mengungkapkan kerentanan secara bertanggung jawab melalui program bug bug. Ini telah sangat sukses, dengan Google membayar $ 1,3 juta dolar pada tahun 2014 saja.

Meskipun ada baiknya menunjukkan bahwa beberapa perusahaan - seperti Oracle Oracle Ingin Anda Berhenti Mengirimkan Bug ke Mereka - Inilah Mengapa Itu GilaOracle dalam air panas atas posting blog sesat oleh kepala keamanan, Mary Davidson. Demonstrasi tentang bagaimana filosofi keamanan Oracle ini berangkat dari arus utama tidak diterima dengan baik di komunitas keamanan ... Baca lebih banyak - mencegah orang melakukan riset keamanan pada perangkat lunak mereka.

Tetapi masih akan ada orang yang bersikeras menggunakan pengungkapan penuh, baik karena alasan filosofis, atau untuk hiburan mereka sendiri. Tidak ada program bug bug, tidak peduli seberapa murah hati, dapat mengatasinya.