Chapter 3 Vulnerability (IT_Ethics_Handbook_IT_Professionals)

Introduction

Penemuan sistem kerentanan dalam perangkat lunak dan sistem operasi yang tidak dapat dihindari dalam teknologi informasi (TI) industri. Terlepas dari waktu yang dihabiskan dalam pengujian selama pengembangan produk, kekurangan hampir selalu hadir selama proses awal peluncuran. Berdasarkan masalah umum ini, orang akan berpikir sebuah sistem untuk menemukan dan memperbaiki kelemahan-kelemahan teknologi tersebut. Namun, proses industri saat ini untuk mengungkapkan jarak kerentanan dari tidak melakukan apa-apa sama sekali untuk merusak proses bisnis oleh membocorkan data kerentanan komunitas topi hitam.

Ini kurangnya struktur dalam berkomunikasi dan memperbaiki kekurangan produk yang melibatkan beberapa perdebatan dalam keamanan informasi komunitas, yang telah berlangsung selama hampir sepuluh tahun. Berbagai sisi dalam debat ini mengungkapkan kekhawatiran / masalah yang valid keduanya untuk melawan berbagai cara pengungkapan seperti pengungkapan penuh versus pengungkapan terbatas. Perdebatan ini kuat mengakibatkan pertimbangan istilah baru yang disebut "pengungkapan bertanggung jawab," yang dibahas pada akhir bab ini.

Bab ini membahas berbagai sudut pandang dan isu-isu etis yang sesuai dari pengungkapan kerentanan keamanan. Bab ini dimulai dengan pertimbangan gagasan populer untuk ketidak pengungkapan, menangani Apakah Anda bahkan dapat mengontrol informasi dan jika itu tepat pernah untuk menghindari proses pengungkapan sama sekali.

Konsekuensi Etika melakukan pengungkapan penuh, termasuk bagaimana mereka mempengaruhi komunitas TI dan komunitas topi hitam.

Kami kemudian menyelidiki bagian pada pengungkapan publik dan tugas etis untuk memperingatkan. Mengikuti pengungkapan publik adalah pengungkapan terbatas. Pengungkapan terbatas merupakan modifikasi dari pengungkapan penuh dimana perusahaan mengungkapkan informasi yang cukup tentang kelemahan sistem bahwa klien mereka mendapatkan kesadaran akan masalah, tapi tidak cukup data untuk topi hitam penyalahgunaan pengungkapan terbatas. Setelah kita berbicara tentang berbagai bentuk mengungkapkan kelemahan dalam produk-produk keamanan informasi, kita membahas bagaimana hacker penyalahgunaan kekurangan tersebut. Kami kemudian mempertimbangkan etika dan bagaimana mereka mengatasi kekurangan produk.

Akhirnya, kami menyimpulkan dengan pertimbangan paradigma baru pengungkapan yang bertanggung jawab, dan apakah ada cara komunitas TI dapat berguna dan pengungkapan bertanggung jawab tanpa memperingatkan komunitas topi hitam untuk kerentanan sistem.

Vulnerability Nondisclosure

Sebuah ketidak penyingkapan kebijakan dalam perusahaan berarti bahwa siapa saja yang menandatangani perjanjian menjaga rahasia untuk menjaga kerentanan informasi dalam organisasi itu yang erat sehingga tidak seorang pun di luar organisasi, terutama umum yang pernah belajar keberadaan kerentanan produk. Beberapa vendor dan lembaga-lembaga keamanan mencoba untuk mempromosikan kebijakan ketidak penyingkapan. Mereka merasa perlu untuk mengendalikan kerentanan informasi dan hanya dipercaya individu menerima informasi tentang produk atau kekurangan sistem. Dengan cara ini, bisnis percaya mereka dapat melindungi rentan sistem sampai didapatkan perbaikan.

SOAP

Road to Hell Pavement Company, Inc.

Tampaknya perdebatan mengenai pengungkapan kerentanan keamanan adalah sesuatu yang saya senang mengikuti sebagai orang luar. Aku punya pendapat yang kuat, tetapi tidak punya relevansi yang nyata kepada mereka, seperti yang saya punya satu tidak ditemukan atau merasakannya kemungkinan bahwa saya akan. Semua itu berubah beberapa tahun yang lalu, di tengah-tengah beberapa pekerjaan untuk organisasi besar yang harus tetap tak disebutkan namanya karena perjanjian menjaga rahasia yang masih dalam efek. Saya memimpin sebuah tim kecil yang tugasnya adalah untuk menemukan setiap dan semua masalah dengan produk jaringan virtual pribadi (VPN) yang akan dilaksanakan. Sayangnya, tidak hanya kita bisa masalah, kami menemukan banyak masalah, dan itu bahkan tidak selesai memeriksa hal-hal yang kami berharap untuk memeriksa sebelum waktu (dan dana) untuk proyek berlari keluar. Vendor membahas isu-isu pertama tiga yang ditemukan (yang dalam waktu dua hari, kami bahkan sebelum masuk ke pembalikan engineering, saya harus menambahkan), yang merupakan kabar baik. Kabar buruknya adalah bahwa konsensus yang luar biasa tim yang lebih banyak masalah yang mengintai di perangkat lunak, baik di server dan klien akhir. Pada satu titik, salah satu dari orang-orang ketakutan dikukuhkan; seorang teman saya mengeluhkan kepadaku satu hari, satu tahun kemudian, bagaimana seseorang bisa hanya menyalin perangkat lunak klien VPN dari satu mesin yang lain, dan semua informasi (Simpan sandi) yang dibutuhkan untuk login ke VPN remote akan mengikuti dengan direktori yang satu; ini adalah abhorrently buruk keamanan untuk aplikasi tersebut, dan itu semata-mata penyiksaan yang menjaga mulut saya menutup saat aku mendengarkan.

Sayangnya, klien tidak diberikan izin untuk mengungkapkan; mereka tidak pernah akan, dalam segala kemungkinan. Untuk alasan apapun, klien mengikuti vendor yang memimpin pada masalah, dan dengan demikian menentang setiap pengungkapan. Ini sangat disayangkan dalam ekstrem terbesar, seperti yang saya telah menyaksikan banyak organisasi besar dan penting yang mengimplementasikan perangkat lunak selama dua tahun, tidak diragukan lagi tidak menyadari apa yang mungkin terjadi jika topi hitam untuk menemukan kelemahan yang masih menyembunyikan dalam. Hanya bertanya baik tentang mengungkapkan, baik setelah kerentanan dikenal yang tetap, telah membawa ancaman gugatan dari klien; ada sedikit keraguan apa akan terjadi jika kami memutuskan untuk mengungkapkan secara spontan. Tapi ada hal kecil untuk tetap diam tentang masalah-masalah yang dapat mempengaruhi orang lain, baik.

Can You Really Control Information? – Adopting Nondisclosure Policies

Dapatkah Anda benar-benar mengendalikan informasi? – Mengadopsi kebijakan Ketidak Penyingkapan

Dalam sebuah vendor produk perusahaan, kesalahan besar ketika memikirkan ketidak penyingkapan adalah keyakinan bahwa seseorang dapat mengontrol informasi. Tidak ada cara untuk menjamin bahwa individu yang dipilih dapat dipercaya untuk tidak menggunakan kerentanan informasi untuk keuntungan mereka sendiri. Selain itu, beberapa dari orang-orang yang dipekerjakan oleh vendor dan keamanan perusahaan memiliki sejarah yang dipertanyakan. Dapat Anda benar-benar percaya reformasi individu dengan masa lalu karir sebagai topi hitam atau topi abu-abu untuk bertindak secara bertanggung jawab dengan kerentanan informasi?

Conservative mengadopsi kebijakan daku memiliki beberapa keunggulan. Daku memberdayakan pimpinan dan personil TI dengan kontrol atas informasi dalam organisasi. Selain itu, dalam kasus pengungkapan, itu memberi mereka kontrol atas kerentanan informasi, yang akan menjaga informasi yang salah dari tangan topi hitam dan orang jahat atau organisasi lainnya. Gagal untuk mengungkapkan kerentanan sistem membuat reputasi perusahaan yang utuh.Keuntungan nyata dari daku adalah vendor sendirian. Jika vendor dapat menyimpan kerentanan rahasia sementara itu adalah tetap, mereka dapat menghindari pers negatif yang mungkin dihasilkan.

Liberal Sebuah kerentanan ketidak penyingkapan memiliki banyak kerugiannya dari pada keuntungannya. Tidak ada cara untuk menjamin bahwa komunitas topi hitam atau penyerang berbahaya lainnya sudah memiliki kerentanan informasi atau bahwa mereka tidak akan menemukannya sendiri sebelum pengungkapan publik yang dibuat. Ada empat alasan utama mengapa kebijakan ketidak penyingkapan kerentanan adalah ide yang sangat buruk.

Pertama, jika kerentanan informasi bocor atau ditemukan secara bersamaan, komunitas topi hitam memiliki kesempatan untuk secara aktif mengeksploitasi kerentanan tanpa pengetahuan umum. Sistem akan dibiarkan terbuka selama waktu yang dibutuhkan vendor perangkat lunak untuk menambal produk.

Kedua, karena kerentanan tidak diungkapkan kepada publik, administrator tidak memiliki kesempatan untuk melindungi kerentanan sistem. Jika vendor gagal untuk mengungkapkan kerentanan sistem serius, klien mereka akan menentukan mereka tidak etis dan bahkan tidak jujur.

Ketiga, karena ada pers negatif untuk vendor perangkat lunak, mereka tidak termotivasi untuk memperbaiki cacat secara tepat waktu.

Keempat, sangat sulit untuk jelas mendefinisikan pemilihan terpercaya individu dengan akses ke kerentanan sensitif informasi. Karena alasan ini, kebijakan ketidak penyingkapan jelas kurang diinginkan.

RINGKASAN

Kerentanan dalam kebanyakan kasus adalah ide yang buruk untuk semua alasan yang disebutkan dalam sudut pandang liberal. Gagal untuk mengungkapkan kekurangan sistem cenderung menyebabkan lebih berbahaya daripada baik. Namun, dari sudut pandang vendor, ketidak penyingkapan mungkin berguna dalam beberapa situasi ketika Anda dapat dengan cepat memulihkan kecacatan sehingga tidak menimbulkan publisitas yang negatif bagi vendor.

The Black Hat Community – Vulnerability Issues and Organizations

Komunitas topi hitam- Isu-isu kerentanan dan organisasi

Komunitas praktik topi hitam kebijakan ketidak penyingkapan. Ketika topi hitam menemukan kerentanan, mereka menyimpan informasi atau mendistribusikannya hanya pada grup topi hitam. Topi hitam ini kemudian menggunakan kerentanan untuk menembus sistem yang dilindungi untuk tujuan rahasia apa pun yang mereka inginkan. Akhirnya informasi kerentanan kebocoran ke dalam forum publik. Namun, sebelum waktu ini berakhir, sistem dan administrator mereka tidak memiliki pertahanan terhadap eksploitasi. Apakah organisasi suka topi hitam yang memiliki hak untuk menyembunyikan masalah kerentanan untuk tujuan jahat?

Conservative komunitas topi hitam tidak etis sifatnya. Mereka hanya menambahkan tambahan perilaku tak tertahankan karena gagal untuk mengungkapkan kelemahan sistem ketika mereka menemukan mereka.

Liberal setiap orang memiliki hak untuk informasi. Menyisihkan serangan berbahaya yang berasal dari ketidak penyingkapan informasi, komunitas topi hitam mungkin atau mungkin tidak mengungkapkan kelemahan informasi mereka menemukan. Ini sempurna etis untuk mengumpulkan informasi dan tetap diam tentang data. Etika jatuh ke dalam penggunaan informasi yang dikumpulkan.

RINGKASAN

Etika dan komunitas topi hitam adalah subjek yang menarik. Mengenai ketidak penyingkapan, beberapa mungkin berpendapat mereka memiliki hak untuk mengumpulkan dan menahan informasi, sementara orang lain berpendapat bahwa karena apa yang orang-orang ini lakukan dengan informasi yang mereka kumpulkan niat mereka menunjukkan bahwa mereka tidak memiliki hak etis untuk mengumpulkan informasi atau gagal untuk mengungkapkan kelemahan sistem.

Full Disclosure

Pengungkapan penuh

Pengungkapan penuh berarti banyak hal yang berbeda tergantung pada orang yang Anda berbicara dengan dan kerentanan bermain. Apa melakukan pengungkapan penuh berarti bagi Anda? Dalam buku istilah, definisi pengungkapan penuh adalah proses luas penyebaran informasi sebanyak mungkin tentang produk atau sistem kerentanan jadi korban yang potensial memiliki informasi yang sama seperti para penyerang potensial. Revelation jenis pengungkapan ini memastikan bahwa pengembang produk dan klien dengan rencana kelemahan produk memiliki waktu yang diperlukan untuk melaksanakan tindakan defensif terhadap sistem kerentanan.

Ada empat cara utama calon korban memastikan sistem mereka menahan kerentanan setelah pengungkapan penuh.Yang pertama adalah untuk mengaktifkan sistem perlindungan dengan mengembangkan dan mengimplementasikan Intrusion Detection System (IDS) tanda. Tanda IDS menyediakan aman deteksi mengeksploitasi bersangkutan. Sarana kedua untuk perlindungan menerapkan memperbaiki sementara atau solusi sepserti menutup layanan rentan atau menghalangi lalu lintas di firewall. Ketiga alat deteksi oleh administrator sistem yang memanfaatkan dieksploitasi kode, adalah untuk memindai jaringan untuk sistem rentan atau untuk menguji kerentanan kemungkinan sistem belum ditambal. Akhirnya, pada sisi vendor, programmer produk bersangkutan dapat meninjau struktur cacat dan mencoba untuk menghindari situasi yang sama dalam pembangunan masa depan.

Mereka yang mendukung pengungkapan penuh berpendapat beberapa keuntungan untuk proses ini. Bagian ini membahas pengungkapan penuh dari sudut pandang etis konservatif dan liberal.

Ethically Handling Security

Vulnerabilities – Who do You Notify?

Etis penanganan keamanan Kerentanan-Siapa yang kamu beritahu?

Anda adalah seorang konsultan insinyur jaringan yang melakukan diagnostik pada pekerjaan. Anda menemukan kerentanan keamanan di parah dalam firewall dibeli dari vendor solusi. Dalam menanggapi kerentanan ini, Anda menginstal firewall baru, lebih aman solusi dari vendor lain. Apa yang Anda lakukan dengan informasi kerentanan yang Anda miliki tentang produk lain?

Conservative memanggil rekan kerja Anda dan memperingatkan mereka dari masalah. Segera memberitahu Computer Emergency Response Team (CERT) kerentanan sehingga mereka dapat memberitahukan vendor dan mempublikasikan fakta setelah vendor telah tetap masalah dan diungkapkan kelemahan produk sendiri. Menghindari langsung penerbitan kerentanan untuk melindungi reputasi Penjual dan Anda sendiri, karena bisnis Anda menggunakan solusi Penjual dan rentan.

Liberal memperingatkan semua orang yang Anda tahu. Melakukan pengungkapan penuh, karena CERT lambat dalam mengeluarkan peringatan yang tepat dan banyak bisnis mungkin mengalami hack berbahaya sementara itu. Menemukan seorang peneliti terkenal yang bersedia menerbitkan kerentanan. Pengungkapan penuh adalah jawaban yang tepat karena ini memotivasi vendor untuk menyediakan tepat waktu patch atau solusi untuk kerentanan baru. Jika vendor gagal memperbaiki tepat waktu dan pengungkapan kerentanan keamanan penuh umum, media negatif dihasilkan akan menyebabkan kerusakan vendor reputasi dan pendapatan. Selanjutnya, untuk menghindari media negatif di masa depan, Anda akan memaksa vendor untuk menghasilkan software yang lebih baik untuk menghindari jenis media yang kedua kalinya.

RINGKASAN

Ada dua titik pandang ketika membuat keputusan untuk melakukan pengungkapan penuh. Yang pertama adalah untuk mengikuti rantai komando dimulai dengan memberitahukan organisasi Anda dan klien Anda, kemudian membawa kelemahan untuk sebuah organisasi yang memenuhi syarat yang menangani proses pengungkapan dari sana, biasanya dalam cara pengungkapan terbatas (dibahas nanti dalam bab ini). Sudut pandang kedua segera mengungkapkan semua informasi kerentanan karena mereka merasa bahwa organisasi seperti CERT terlalu lambat dalam melaporkan kerentanan dan klien perlu untuk mengetahui rincian lengkap sesegera mungkin untuk lebih baik mempersenjatai diri terhadap serangan. Mana berarti Anda mengadopsi, mempertimbangkan dampak dari kedua sebelum bertindak.

SOAP

Permainan pengungkapan

Pengungkapan kerentanan keamanan adalah taruhan tinggi permainan, dengan banyak ketenaran akan seseorang atau tim yang menemukan kerentanan, dan banyak telur di wajah perusahaan dengan kerentanan. Hal ini dapat sangat frustasi untuk menjadi mapan, sah kerentanan penemuan tim yang sepatutnya akan memberitahu perusahaan ketika kerentanan ditemukan, dan kemudian menunggu perusahaan untuk merespon dan patch kerentanan. Banyak peneliti telah "meraup" oleh orang lain, kurang teliti yang akan melepaskan kerentanan tanpa memberitahukan perusahaan terkena, lama setelah peneliti pertama telah ditemukan dan biasanya didokumentasikan kerentanan sama. Kerahasiaan dan kerahasiaan yang sering kunci untuk siklus discovery-patchannouncement pengungkapan kerentanan keamanan berikut hari ini.

Performing a Full Disclosure –

How Much do Others Know Already?

Melakukan pengungkapan penuh-Berapa banyak yang orang lain sudah tahu?

Anda akan melakukan pengungkapan penuh termasuk kode script dan rincian lainnya tentang kelemahan keamanan dalam sistem browser Internet bisnis Anda memanfaatkan.Anda berpendapat bahwa Anda harus sepenuhnya mengungkapkan semua informasi karena Anda menganggap organisasi seperti Black Hat sudah memiliki informasi dan Anda ingin vendor dan klien memiliki informasi ini untuk menangkap setiap kerusakan yang disebabkan oleh serangan berbahaya. Apakah Anda benar dalam asumsi ini?

Conservative meskipun memang benar bahwa komunitas berbakat topi hitam mungkin memiliki pengetahuan sebelumnya dari mengeksploitasi, gerombolan script tidak. Sepenuhnya mengungkapkan kerentanan termasuk kode dieksploitasi. Setelah pengungkapan penuh, script akan memiliki mengeksploitasi otomatis dan dapat meluncurkan serangan kepada siapa pun dalam komunitas yang memanfaatkan pertanyaan browser. Bahkan jika script kiddies tidak menyadari dari pengetahuan teknis, mereka mungkin memiliki apa yang mereka perlu untuk melancarkan serangan dari pengungkapan. Selain itu, jika topi hitam yang mampu melakukan tidak memiliki pengetahuan tentang kerentanan baru, pengungkapan penuh tetes informasi ini di lap dan membuat itu secara signifikan lebih mudah bagi mereka untuk mengembangkan dieksploitasi kode dan otomatis alat mereka.

Liberal penuh pengungkapan pendukung berasumsi bahwa komunitas hacker topi hitam itu sudah sadar produk kerentanan oleh sifat organisasi topi hitam. Dengan sepenuhnya mengungkapkan informasi kerentanan, administrator sistem rentan memperoleh data yang diperlukan untuk mengambil penghalangan dan memberikan perlindungan. Pengungkapan penuh sangat penting sehingga administrator dan programer sepenuhnya memahami kerentanan untuk mencegah dan membela terhadap mereka. Melalui sistem pengungkapan penuh, administrator dan programer memperoleh akses ke rincian teknis lengkap kerentanan dan akibatnya dapat mengambil tindakan defensif yang sesuai.

RINGKASAN

Meskipun konsep pengungkapan penuh tidak menghalangi vendor pemberitahuan, sebagian besar kaum konservatif menunjukkan kurangnya tenggang waktu selama vendor dapat mengatasi kelemahan sebagai kelemahan utama. Dalam pengungkapan penuh, vendor menerima pemberitahuan simultan dengan waktu pengungkapan kerentanan informasi kepada semua orang lain. Karena ini, sistem rentan selama jumlah waktu yang dibutuhkan vendor untuk alamat kerentanan dan klien untuk menempatkan tindakan-tindakan pertahanan. Namun, dari sudut pandang liberal, menunggu untuk posting pengungkapan penuh memungkinkan bom waktu untuk pergi dalam organisasi Anda. Gagal untuk melakukan pengungkapan penuh menghalangi sistem administrator dari waktu yang memadai diperlukan untuk langkah-langkah defensif yang efektif internal.

Public Disclosure

Pengungkapan publik

Tahap publisitas siklus hidup kerentanan dimulai setelah pengujian menyeluruh bagian pengembangan usaha. Selama tahap ini, pencetus, Koordinator, dan penjual sama mengembangkan isi dari pengungkapan publik dalam cara yang menyenangkan untuk semua pihak. Proses pengungkapan publik ini mirip dengan pengungkapan penuh dengan satu pengecualian; Pengungkapan publik tidak akan menyertakan kode dieksploitasi. Namun, pengungkapan penuh rincian teknis disertakan dengan bagian diuji, potensi workarounds, dan mungkin tanda IDS. Idenya di sini adalah untuk memberikan administrator dan programer informasi yang cukup untuk mempertahankan terhadap kerentanan, tetapi membuat sulit bagi script untuk meluncurkan serangan yang mengeksploitasi kerentanan. Waktu dari pengungkapan publik dilakukan harus bertepatan dengan ketersediaan. Namun, jika ada kebocoran dikenal dari kerentanan atau itu sudah sedang aktif dieksploitasi pengungkapan publik akan mendahului bagian ketersediaan.

ISS Handling Vulnerabilities – Should You Pay?

ISS penanganan kerentanan-yang harus Anda bayar?

Yang kedua setengah dari 2002, Internet Security Systems (ISS) menerima banyak kritik atas penanganan beberapa kerentanan. ISS menemukan kekurangan dalam Internet Software Consortium mengikat perangkat lunak, perangkat lunak server Apache Web, dan Sun Microsystems Solaris X Windows layanan depan. Dalam semua kasus, ISS diberitahu vendor dan bekerja dengan mereka untuk mengkoordinasikan pengungkapan publik dengan ketersediaan patch. Terlepas dari siapa yang bersalah dalam penanganan setiap kejadian, prosedur ini tidak diterima dengan baik oleh komunitas umum. Dalam hal kerentanan ISC mengikat, patch tidak didistribusikan cukup cepat.Vendor patch untuk masalah Solaris Font cacat dan harus diingat. Akhirnya, Apache patch tidak didistribusikan sampai setelah pengungkapan publik, topi hitam meskipun telah mengeksploitasi kerentanan selama lebih dari empat bulan.

Karena acara ini, ISS adalah termotivasi untuk melepaskan kebijakan publik yang menjelaskan setiap langkah yang dibutuhkan ketika mengungkapkan kerentanan baru ditemukan. Kebijakan pengungkapan ISS berisi beberapa konsep-konsep kunci pengungkapan yang bertanggung jawab dengan satu pengecualian: ISS menyatakan bahwa itu akan mengungkapkan kerentanan untuk membayar pelanggan layanan satu hari setelah memberitahukan vendor. Selanjutnya, mereka mungkin menggabungkan pengujian untuk kerentanan baru dalam produk keamanan mereka. Hal ini menarik untuk dicatat bahwa salah satu tujuan utama dari pengungkapan yang bertanggung jawab untuk menjaga pengetahuan tentang kerentanan dalam lingkaran terkecil orang sampai patch dapat dikembangkan dan dibuat publik. Apa itu untuk mencegah topi hitam dari berlangganan layanan berlangganan ISS dan menerima pemberitahuan tentang kerentanan satu hari setelah vendor diberitahu? Apakah ini jenis selektif pengungkapan etis?

Conservative ISS tidak akan mengungkapkan rincian teknis tentang kerentanan, tapi topi hitam akan tahu apa jenis kerentanan yang ada dan di mana bagian dari vendor produk.Pengetahuan itu dapat membantu topi hitam dalam mengembangkan mengeksploitasi dan menggunakannya pada sistem rentan sebelum patch penjual tersedia. Selain itu, hal ini tidak etis sesuai untuk membuat uang dari eksploitasi informasi.Ini menempatkan ISS di posisi mengorbankan karena mereka tidak membuat uang kecuali ada eksploitasi.

Liberal membuat uang dari lewat dieksploitasi informasi adalah perdagangan yang terhormat. Jika itu penting bagi suatu organisasi untuk memperoleh informasi ini, mereka akan bersedia membayar untuk itu. Ini memakan waktu dan energi untuk secara akurat penelitian potensi kerentanan dan alamat mereka cerdas. Topi hitam organisasi mungkin berakhir dengan akses ke data ini; Namun, tidak ada yang tidak etis tentang informasi.

RINGKASAN

Beberapa mungkin menganggap itu tidak etis untuk menagih uang untuk informasi produk kerentanan dan berpendapat bahwa layanan jenis ini menyediakan data kepada komunitas topi hitam dengan biaya sementara tidak semua komunitas TI akan memiliki akses ke data kerentanan. Orang lain berpendapat bahwa tidak ada yang salah dengan membuat keuntungan dari proses pengungkapan, Apakah komunitas topi hitam mengambil informasi dengan cara ini atau tidak.

Vulnerability Disclosure by Security Research Companies – Should They Tell?

Pengungkapan kerentanan keamanan oleh keamanan

Perusahaan penelitian-yang harus mereka katakan?

Dengan frekuensi yang lebih besar, perusahaan penelitian keamanan menerima kritik untuk mengungkapkan kerentanan untuk tujuan tunggal menghasilkan liputan pers menguntungkan.Liputan media perusahaan keamanan menerima mungkin berarti pendapatan yang substansial dalam bentuk pelanggan baru atau lebih besar kontrak. Karena ini, komunitas mulai mempertanyakan motivasi yang benar di belakang beberapa organisasi penelitian dan pengungkapan kerentanan. Dalam beberapa kasus, pengungkapan kerentanan oleh perusahaan keamanan adalah hasil dari stres intens pengujian produk. Kemungkinan kerentanan ini datang ke kehidupan di luar lingkungan laboratorium palsu diproduksi kecil, jika tidak mustahil. Harus pengungkapan kerentanan ditemukan di laboratorium di bawah kondisi yang tidak biasa seperti intensif stres pengujian dibuat tersedia untuk umum?

Conservative Mempublikasikan kerentanan penemuan hanya membantu hacker dan tidak beretika. Jika Anda menerapkan jenis tekanan yang tepat untuk hampir setiap vendor produk, Anda akan menemukan kelemahan. Ancaman nyata adalah tujuan dari pengungkapan penuh, tidak "apa jika" skenario. Ini juga merupakan lingkungan dimana perusahaan keamanan dapat memilih pada vendor tertentu oleh stres pengujian hanya produk-produk mereka.Hasil ilmiah tidak cukup meyakinkan untuk mendukung mempublikasikan uji ketahanan kecuali jika hal ini dilakukan oleh sebuah badan ahli yang telah ada untuk mendapatkan dari penerbitan hasil tersebut.

Liberal mengungkapkan semua data tentang sistem yang umum digunakan adalah alat yang efektif terhadap serangan berbahaya. Berdasarkan data klien menentukan jika kelemahan sistem akan pernah terjadi dalam lingkungan produksi mereka. Mempublikasikan kerentanan sistem di bawah lingkungan stres pengujian merupakan aset kepada komunitas ini.

RINGKASAN

Tergantung pada jenis tes stres, ketidaktepatan iklan kerentanan sistem mungkin terjadi dan tidak perlu menodai reputasi khusus produk atau vendor solusi, sehingga jenis keterbukaan informasi yang tidak akurat. Namun, semakin banyak informasi administrator sistem memiliki pembuangan mereka semakin baik mereka dapat melindungi sistem informasi yang di biaya mereka.

Ethical Duty to Warn

Tugas etis untuk memperingatkan

Orang atau bisnis memiliki "kewajiban untuk memperingatkan" jika penggunaan produk mereka dapat menyebabkan kerugian kepada pengguna.Bisnis pertama kewajiban adalah untuk mendesain ulang produk atau menerapkan patch yang diperlukan untuk menghilangkan bahaya. Jika karena alasan tertentu yang tidak bisa terjadi, orang atau bisnis harus menyediakan cara lain untuk melindungi pengguna dari bahaya yang terkait dengan produk mereka. Jika masalah masih ada, mereka harus cukup memperingatkan pengguna tentang hal itu. Jika bug atau kerentanan yang terbuka dan jelas, kemudian ada tugas etis untuk memperingatkan.

Ini berarti bahwa produk dan vendor solusi harus menerapkan beberapa pertimbangan harapan konsumen dan melakukan tes risiko yang sesuai. Karena produsen ahli pada produk, gagal untuk memberi amaran tentang kerentanan oleh seorang karyawan adalah perilaku yang tidak etis.

Bagian ini membahas dua skenario yang berbeda tugas untuk memperingatkan.Yang pertama menganjurkan pendekatan yang lebih konservatif merekomendasikan peringatan produk kelemahan, dan kedua mengeluarkan alamat kasus ketika itu mungkin tidak sesuai untuk memperingatkan komunitas tentang kelemahan sistem.

Writers Exposing System Weaknesses –

Should You Disclose All Information?

Penulis mengekspos kelemahan sistem -

Harus Anda mengungkapkan semua informasi?

Anda menulis kertas putih untuk sistem operasi baru. Hal ini umum lagi kekuatan dan kelemahan dalam kertas putih, tetapi hanya untuk tingkat tertentu.Sistem operasi yang Anda menulis tentang memiliki kelemahan keamanan yang serius. Itu tugas Anda untuk menuntut mengungkapkan informasi penting ini kertas putih atau melalui cara lain komunikasi?

Conservative Integritas sistem keseluruhan sangat penting ketika menjual produk baru, terutama sistem operasi. Bersikeras bahwa semacam peringatan pergi ke kertas putih dan sesuai sistem dokumentasi.Tanpa ini, perusahaan akan menempatkan dirinya pada risiko kerusakan sistem yang ditimbulkan karena sistem operasi. Menjelaskan pentingnya ini ke manajemen senior.Mereka akan menghargai bahwa Anda membawa masalah ini untuk perhatian mereka.

Pertama, mirip dengan bentuk lain dari pemberi informasi disebutkan, Anda harus selalu memberitahukan vendor sebelum pengungkapan publik apapun. Jangan memaparkan informasi di luar vendor. Melakukan kontak ini sedemikian rupa untuk mengkonfirmasi bahwa vendor telah menerima pemberitahuan. Jika Anda merasa Anda tidak dapat berkomunikasi langsung ke vendor tentang kerentanan sistem, menggunakan pihak ketiga Koordinator yang akan membantu memfasilitasi komunikasi penemu dan vendor.

Liberal memang bukan tempat Anda sebagai penulis memerlukan dimasukkannya sistem kerentanan informasi tertentu kertas putih Anda akan menerima bayaran untuk menghasilkan.Hal ini terutama berlaku jika informasi yang berpotensi merugikan penjualan produk. Pikiran bisnis Anda sendiri dan melakukan pekerjaan mereka menyewa Anda untuk melakukan. Meninggalkan fakta-fakta dan masalah ke manajemen.

RINGKASAN

Menentukan apakah itu adalah tugas Anda sebagai seorang penulis untuk memperingatkan pembaca Anda dari masalah sistem adalah pilihan yang Anda harus membuat. Anda etis berhak untuk tugas untuk memperingatkan? Manfaat peringatan pembaca Anda adalah mereka akan tahu Anda teliti dalam penelitian Anda dan dapat dipercaya, yang pada gilirannya meningkatkan reputasi Anda sebagai penulis. Sisi bawah memberikan peringatan tersebut adalah bahwa beberapa perusahaan mungkin tidak memilih untuk mempekerjakan Anda karena mereka hanya ingin seseorang untuk menulis, tidak memberitahu mereka apa yang harus dilakukan dan memaksa mereka untuk mengungkapkan setiap titik di bawah produk mereka.

Instilling Public Fear with Full Disclosures – Err on the Side of Caution?

Menanamkan rasa takut yang umum dengan penuh pengungkapan-berbuat salah di sisi hati-hati?

Anda bekerja untuk menara kontrol lalu lintas udara dan Anda menemukan kerentanan keamanan di sistem dalam salah satu perangkat lunak yang Anda gunakan untuk melacak pesawat.Hal ini sangat besar karena itu berpotensi membahayakan banyak nyawa. Apakah etis dapat diterima secara terbuka mengungkapkan informasi ini di televisi nasional? Kau tahu jenis pengungkapan dapat menanamkan rasa takut dan panik di depan umum.

Conservative jenis tertentu dari pengungkapan terbaik ditangani secara lebih pribadi antara penemu awal kerentanan dan vendor. Selama waktu setelah kontak awal dan hingga pengungkapan publik, semua jalur komunikasi antara penjual, penemu dan pemula harus disimpan terbuka dan rahasia.Setiap miskomunikasi selama proses seluruh pengungkapan bisa mengakibatkan pengungkapan prematur dan potensi umum panik. Penting bahwa vendor berusaha mereproduksi kerentanan untuk memverifikasi keberadaannya.Pencetus harus memberikan vendor dan koordinator dengan semua diperlukan informasi dan bantuan reproduksi dengan cara apapun.Ini akan menentukan apakah bahkan ada kesalahan. Mengungkapkan data kerentanan perangkat lunak lalu lintas udara tanpa benar-benar menegaskan kelemahan sistem ini benar-benar tidak etis. Kerentanan jenis ini harus ditangani dengan cara ini tanpa pengungkapan publik.

Liberal komunitas memiliki hak untuk mengetahui jika sistem kontrol lalu lintas udara untuk pesawat dan Bandara yg tdk berlaku atau rusak.Ini adalah kasus di mana pengungkapan publik dapat menyelamatkan nyawa dan informasi harus diterbitkan segera setelah diketahui.

RINGKASAN

Penerbitan informasi segera setelah penemuan ini tidak selalu ide yang baik. Terbaik untuk menghubungi vendor dan melakukan tes diperlukan untuk memvalidasi bahwa sebenarnya ada kerentanan berlaku. Setelah Anda menemukan ada kerentanan yang akurat adalah pilihan etis untuk menentukan apakah Anda merasa Anda memiliki tugas etis untuk memperingatkan komunitas umum dan masalah kontrol lalu lintas udara atau menangani masalah secara lebih rahasia.

Limited Disclosure

Pengungkapan terbatas

Pengungkapan terbatas ini mirip dengan ketidak penyingkapan karena berbagi informasi kerentanan terjadi dalam sekelompok kecil orang.Perbedaannya unik adalah bahwa ketidak penyingkapan terjadi dalam organisasi dan pengungkapan terbatas mungkin termasuk individu di luar organisasi pada organisasi perbedaan. Selama fase awal dari pengungkapan terbatas, akses ke rincian lengkap tentang kerentanan diberikan untuk sekelompok kecil orang.Kelompok ini berpotensi terdiri dari tiga berbagai pihak, pemberi informasi, vendor, dan mungkin Koordinator pihak ketiga. Tidak seperti penuh pengungkapan, proses pengungkapan terbatas tidak memberikan rincian lengkap teknis kerentanan pada saat akhir pengungkapan. Rilis rincian tersebut terjadi hanya ketika vendor perbaikan kelemahan sistem.Alasan untuk ini batas data teknis adalah pendukung pengungkapan terbatas mengklaim bahwa pengguna, programmer, dan administrator tidak memerlukan informasi teknis untuk patch atau mempertahankan sistem. Selain itu, penggemar pengungkapan terbatas menyatakan bahwa pengungkapan informasi teknis lengkap hanya membantu komunitas topi hitam.

Ada beberapa masalah dengan konsep pengungkapan terbatas. Sebagai dengan ketidak penyingkapan, kita menghadapi dilema yang mempercayai dengan informasi awal kerentanan. Ini akan sangat sulit untuk menegakkan etika perilaku di antara mereka yang dapat berdiri untuk mendapatkan dari pengungkapan atau eksploitasi kerentanan yang tidak diketahui.

Tanpa pengungkapan publik yang wajib, ada apa-apa untuk memotivasi vendor untuk mengembangkan memperbaiki tepat waktu. Sejak vendor dapat menunda pengungkapan akhir sampai mereka memperbaiki Cacat, menunda akhir pengungkapan publik pada akhirnya penundaan perbaikan tanpa batas.

Akhirnya, karena jumlah informasi teknis dalam pengungkapan awal sangat terbatas, pelanggan mungkin tidak dapat mengambil tindakan defensif awal.

IDS Signatures and Defensive Measures – Should You Provide Details?

Tanda IDS dan ukuran defensif -Anda harus memberikan detail?

Anda adalah seorang administrator sistem dan mendengar desas-desus bahwa ada masalah dengan salah satu alat administrasi Anda.Vendor telah diungkapkan apa-apa untuk Anda sejauh ini.Tanpa informasi teknis rinci, tanda tangan ID tidak dibuat untuk mengatasi masalah ini.Anda tahu bahwa sistem deteksi Anda tidak akan efektif karena pengembangan alat untuk mendeteksi sistem rentan dan tes patch Penjual akan menjadi mustahil untuk mengembangkan karena informasi tentang kerentanan tidak diungkapkan.Dengan semua fakta-fakta ini dalam bermain, Apakah Anda sebagai administrator sistem merasa bahwa sebuah perusahaan memiliki hak etis untuk menolak untuk memberikan pengungkapan pada rincian teknis kelemahan produk mereka?

Conservative dari sistem administrator sudut pandang itu tidak etis untuk menunda atau menghindari mengungkapkan kerentanan produk.Penemuan kerentanan sudah aktif mengeksploitasi sistem adalah no-brainer. Kelemahan harus melalui pengungkapan penuh sehingga mereka sistem administrator dapat membuat tanda tangan id menanggapi masalah dan memperbarui teknologi defensif sesuai yang dibutuhkan. Dalam situasi ini, sistem eksposur dan eksploitasi adalah bencana selama periode waktu sementara vendor penundaan pengungkapan sampai mereka siap untuk merilis patch. Bahkan jika penerbitan pengungkapan akhir terjadi sebelum vendor rilis patch, administrator masih kekurangan informasi yang cukup diperlukan untuk menggunakan langkah-langkah penanggulangan yang diperlukan. Akhirnya, tanpa pemahaman lengkap tentang struktur Cacat, tim pemrograman untuk penjual produk akan terus membuat kesalahan yang sama ketika coding produk masa depan. Semua alasan ini adalah padat argumen untuk keperluan pengungkapan penuh.

Liberal bahkan meskipun gagal untuk mengungkapkan informasi yang mungkin berbahaya bagi klien, vendor tidak etis diharuskan untuk melakukan pengungkapan penuh. Pengungkapan terbatas tidak etis. Pengungkapan terbatas melindungi vendor dan klien informasi sensitif dari jatuh ke tangan yang salah.

RINGKASAN

Masalah ini adalah seorang pelaku versus praktis diskusi. Dari sudut pandang sistem administrator, dalam kebanyakan kasus penuh pengungkapan diperlukan bagi mereka untuk secara memadai melakukan layanan mereka untuk semua alasan yang disebutkan. Namun, beberapa orang mungkin masih tidak merasa bahwa vendor etis diperlukan untuk menghasilkan penuh pengungkapan pada produk kerentanan, dan bahwa pengungkapan tersebut feed topi hitam komunitas dan script.

Black and White Hat Hackers

Hacker topi hitam dan putih

Orang-orang yang menentang pengungkapan kerentanan keamanan penuh melakukannya karena mereka merasa bahwa penerbitan kerentanan sistem menyediakan membuka "black hat hacker" untuk melakukan serangan berbahaya pada penjual produk. Mengungkapkan rincian kelemahan sistem bahan bakar hacker dengan pengetahuan yang mereka butuhkan untuk penyalahgunaan kelemahannya. Selain itu, "white hat hacker" yang bertanggung jawab adalah untuk menemukan kerentanan, memiliki serangkaian isu-isu moral untuk mengatasi ketika reverse rekayasa produk untuk tujuan perlindungan menemukan kerentanan.

Bagian ini membahas cara di mana hacker penyalahgunaan proses pengungkapan penuh. Ini juga membahas dampak etis dari penyalahgunaan tersebut, baik kepada para hacker dan orang-orang yang menyediakan pengungkapan penuh. Selanjutnya, kita menggali ke dalam topi putih hacker dan reverse engineering produk Apakah etika dari sudut pandang sistem perlindungan.

Hackers Make Use of Vulnerability Disclosures – Is Full Disclosure Necessary?

Hacker memanfaatkan kerentanan pengungkapan- apakah pengungkapan penuh perlu?

Anda bekerja untuk sebuah perusahaan keamanan informasi dan menemukan bukti bahwa topi hitam membuat penggunaan kerentanan sistem operasi yang signifikan.Anda tahu bahwa cara untuk menghindari jenis eksploitasi adalah jika bisnis tidak menyediakan pengungkapan penuh. Dari informasi keamanan point of view, Anda bisa berpendapat bahwa pengungkapan penuh bahan bakar hacker dan dengan demikian tidak etis?

Conservative masalah paling penting untuk profesional keamanan informasi adalah integritas sistem.Pencegahan memperlihatkan kelemahan sistem serangan berbahaya adalah prioritas pertama.Apa pun yang dapat berpotensi menghasilkan serangan memerlukan kerahasiaan dan perlindungan. Meskipun penuh pengungkapan dalam beberapa kasus, dapat mempercepat proses melindungi kerentanan, mereka tanggung-jawab dalam diri mereka sendiri untuk petugas keamanan informasi. Penerbitan serangan kode hanya tidak etis dan memberikan ide-ide baru untuk masa depan serangan. Menyediakan perpustakaan sumber daya coders berbahaya.

Liberal Pengungkapan kepada publik diperlukan bagi pelanggan untuk mempertahankan sumber daya mereka. Bahkan jika penyerang jahat sudah tidak menyadari kelemahan keamanan dan ide-ide kode berbahaya, mereka akan segera menyadari mereka sendiri sehingga tidak menyediakan bahan bakar untuk pekerjaan. Ianya hampir mustahil untuk memberikan keamanan yang efektif untuk sistem ketika petugas keamanan informasi menerima informasi yang jelas mengenai kerentanan sistem.

RINGKASAN

Perdebatan ini pada pengungkapan penuh dipanaskan dan ada tidak ada jawaban yang tepat. Kedua poin of view memiliki kekuatan dan kelemahan. Namun, karena Penjual perlawanan untuk memperbaiki kerentanan keamanan, jalan lebih mungkin yang paling profesional keamanan informasi akan mengambil adalah bahwa pengungkapan penuh. Pengungkapan penuh memaksa vendor untuk menyediakan patch untuk kelemahan keamanan yang diketahui. Jika vendor lebih cepat pada jari kaki mereka ketika menanggapi kelemahan dalam produk mereka, pengungkapan penuh tidak akan menjadi suatu keharusan dan argumen akan terlihat sangat berbeda.

The Government on Hackers – Should You Reverse Code?

Pemerintah pada hacker - Anda harus membalikkan kode?

Departemen Keamanan dunia maya pemerintah AS mendesak topi putih hacker untuk menemukan kerentanan keamanan di vendor perangkat lunak. Namun, pemerintah menginginkan data ini tentang kekurangan produk untuk pergi hanya untuk vendor dan pemerintah.Ini berada dalam kontras langsung apa yang beberapa profesional TI merasa mereka memerlukan ketika menjaga integritas sistem mereka utuh.Pemerintah memungkinkan profesional keamanan untuk menemukan kerentanan, tetapi berkomunikasi bahwa reverse engineering kode dilakukan oleh siapapun selain profesional keamanan komputer adalah untuk tidak bermoral tujuan.Ini berarti bahwa kecuali Anda keamanan informasi ahli Anda tidak melihat terlalu dalam ke Penjual produk untuk menemukan kerentanan, sehingga menghambat kemampuan Anda untuk menerapkan perlindungan yang diperlukan untuk sistem di bawah tanggung jawab Anda. Itu tidak bermoral untuk membalikkan insinyur kode jika tujuan Anda adalah untuk melindungi sistem Anda mengelola atau bekerja dengan?

Conservative Reverse engineering code harus tetap di bidang informasi keamanan profesi dan tidak di tangan sistem administrator atau programmer. Itu tidak etis untuk membalikkan kode insinyur dari vendor bahkan jika tujuan Anda adalah untuk menemukan kerentanan dan melindungi sistem Anda dari kelemahan produk tersebut.

Liberal sistem administrator dan pengembang perlu diingat integritas produk dan lingkungan di bawah wilayah mereka tanggung jawab dan data yang sensitif dalam lingkungan tersebut.Tidak ada yang salah dengan memastikan perlindungan dari pelanggan informasi kartu kredit jika Anda memiliki alasan untuk percaya bahwa produk perangkat lunak yang Anda gunakan untuk memproses transaksi kartu kredit tidak aman.Pilihan yang paling etis dalam keadaan ini adalah untuk merekayasa alat Penjual, menemukan kelemahan, laporkan kepada vendor, dan menerapkan perlindungan pada sistem Anda untuk mencegah penyalahgunaan dari kerentanan ini. Gagal melakukannya akan menjadi tidak etis.

RINGKASAN

Masalah ini sangat sulit untuk memilah-milah karena kompleksitas. Di satu sisi, lembaga pemerintah negara yang membalikkan teknik kode produk 's imoral untuk beberapa profesi teknologi untuk melakukan; di sisi lain, gagal perlindungan yang memadai informasi nasabah adalah tanpa diragukan lagi tidak etis.

Patch Development

Bagian Pengembangan

Selama proses mendeteksi dan memperbaiki kerentanan produk, tahap koreksi dimulai dengan pengembangan patch. Pengembangan patch adalah langkah yang diperlukan ketika menangani produk kerentanan.Rentang waktu yang dibutuhkan untuk melihat sebuah patch yang dihasilkan dari kerentanan penemuan sangat bervariasi tergantung pada vendor dan kompleksitas sistem atau produk kelemahan. Dalam beberapa kasus, patch pengembangan dapat mengambil banyak waktu jika Cacat melekat pada struktur produk.Vendor mungkin juga harus alamat alat serupa lainnya, yang memiliki masalah yang sama dalam lini produk mereka.Hal ini terutama terjadi ketika vendor mengembangkan produk memanfaatkan perpustakaan pusat kode.

Berikut ini adalah contoh yang sangat baik dari rumitnya pengembangan patch sehubungan dengan proses pengungkapan.Kami membahas masalah etis dengan Simple Network Management Protocol (SNMP) kerentanan.Bagian ini juga alamat perangkap rilis patch patch yang menggabungkan sistem perbaikan dan cepat patch yang memacetkan sistem mereka seharusnya untuk memperbaiki.

Taking the Market Advantage – Should You Communicate?

Mengambil keuntungan pasar – harus Anda berkomunikasi?

Anda menemukan kerentanan dalam produk Anda mengembangkan memanfaatkan SNMP. Masalah ini akibatnya ada dalam produk-produk lain yang memanfaatkan SNMP. Pemberitahuan tambahan vendor dan pelepasan rincian kerentanan tersebut yang diperlukan untuk benar pengujian produk mereka untuk kelemahan ini. Namun, jika Anda tidak memberi tahu vendor lainnya dan memperbaiki masalah dalam perangkat lunak Anda, Anda dapat mempublikasikan kesalahan dan mendapatkan keuntungan pasar. Apakah etis untuk gagal untuk mengungkapkan informasi tentang kelemahan SNMP jika itu akan memberi Anda keuntungan pasar?

Conservative keterlibatan beberapa vendor dapat mengakibatkan kebingungan dan miskomunikasi terutama pada masalah yang mempengaruhi pesaing. Karena hal yang benar untuk lakukan adalah untuk berkomunikasi kerentanan SNMP, setiap usaha harus dibuat untuk menjaga semua tindakan terkoordinasi. Jika satu vendor rilis kerentanan informasi prematur, pelanggan tersisa vendor akan dibiarkan terbuka.

Perusahaan harus bekerja sama untuk menguji semua patch dan memastikan mereka afektif untuk berbagai produk memanfaatkan SNMP. Perbedaan dalam lingkungan dan konfigurasi sistem dapat menyebabkan sebuah patch untuk memiliki efek samping negatif. Setelah patch sukses semua produk memanfaatkan SNMP akan aman.

Liberal pengetahuan masalah dalam sumber daya yang dimiliki oleh vendor bersaing menyediakan edge bisnis. Menggunakannya untuk keuntungan Anda. Menemukan masalah dengan sumber yang dipakai bersama dan mengatasinya dalam produk Anda adalah hak prerogatif Anda.Anda etis tidak diharuskan untuk berbagi informasi ini untuk alasan logis.Anda bisa yakin pesaing Anda tidak akan membuat komunikasi Anda. Merebut kesempatan untuk meninggalkan kompetisi dalam debu.

RINGKASAN

Pilihan etis yang jelas untuk gambaran besar adalah untuk berkomunikasi serius kerentanan dalam kode SNMP kepada semua yang digunakan dalam produk mereka. Namun, kebanyakan orang tidak mendasarkan etika pribadi mereka pada kebaikan bagi manusia; mereka mendasarkan mereka pada hal-hal yang lebih kecil dan hubungan pribadi. Sebagian merasa itu bukanlah tanggung jawab etis untuk berkomunikasi SNMP kelemahan pesaing mereka. Mereka banyak bahkan mempertimbangkan komunikasi jenis ini pelanggaran kesetiaan perusahaan.

Combining System Fixes with Security Patches – Adding More Risk?

Menggabungkan sistem perbaikan dengan bagian keamanan - menambahkan lebih banyak risiko?

Satu masalah dengan pengungkapan penuh ini adalah perlombaan untuk membuat sebuah patch yang memperbaiki masalah keamanan.Ketika menangani diungkapkan kerentanan, beberapa perusahaan sering menggabungkan perbaikan sistem dengan keamanan tambalan.Anda sebagai administrator sistem menemukan proses ini merumitkan memperbaiki kerentanan karena dapat mempengaruhi area lain dari sistem Anda. Perbaikan sistem tambahan ditambahkan ke patch menyebabkan masalah-masalah baru muncul, yang tidak dapat dengan mudah dipisahkan. Apakah etis untuk menanggapi pengungkapan penuh dengan menggabungkan perbaikan sistem dengan kerentanan patch? Selain itu, kadang-kadang patch dikembangkan begitu cepat yang berisi kesalahan dan crash sistem ini dirancang untuk memperbaiki. Apakah etis untuk menanggapi pengungkapan penuh dengan mengeluarkan cepat patch, dimana pengujian patch yang tepat tidak terjadi karena pengungkapan penuh?

Conservative Bagian sistem untuk kerentanan dibuka harus independen perbaikan sistem tambahan atau upgrade. Kerentanan keamanan memerlukan solusi yang efektif dilakukan dengan cara yang paling aman yang dapat dicapai. Rumit kerentanan dengan perbaikan sistem tambahan adalah cara yang tidak etis untuk menangani patch keamanan.Hal ini terutama berlaku dalam kasus menciptakan kerentanan patch terlalu cepat tanpa pengujian yang tepat dari patch pada sistem operasi.Selalu ada bahaya meningkatkan kerusakan agak kemudian mengatasi masalah. Pengungkapan penuh bukanlah alasan untuk cepat patch yang menyebabkan masalah sistem muncul.

Liberal Satu hasil pengungkapan penuh ini adalah perbaikan cepat yang tidak efektif atau merusak sistem mereka mencoba untuk alamat.Ini hanyalah bagian dari realitas proses pengungkapan penuh. Itu menekan vendor untuk membuat tanggapan segera bahkan jika mereka tidak siap secara teknis untuk melakukannya. Tidak ada yang salah dengan menggabungkan kerentanan patch dengan tambalan sistem kecil tambahan selama mereka tidak menimbulkan masalah.

RINGKASAN

Mengenai masalah menggabungkan perbaikan dengan bagian kerentanan, beberapa orang mungkin menganggap ini menambah risiko tambahan masalah awal. Orang lain mungkin merasa bahwa memberikan tambahan perbaikan tidak menyebabkan masalah dan mungkin tidak merasa ini adalah masalah etis. Selain itu, ketika sebuah patch tidak tepat diuji, masalah timbul. Ini mungkin merupakan konsekuensi negatif dari proses pengungkapan penuh.

Responsible Disclosure Plans

Rencana pengungkapan yang bertanggung jawab

Tujuan dari "pengungkapan yang bertanggung jawab" adalah untuk memungkinkan pelanggan dari vendor produk cukup waktu untuk melindungi sistem mereka dari eksploitasi dan serangan. Pengungkapan yang bertanggung jawab mengacu pada jumlah waktu yang diperlukan untuk topi hitam untuk menghasilkan serangan setelah memperoleh pengetahuan tentang kerentanan sistem. Serangan berbahaya dapat terjadi setiap saat; Namun, bertanggung jawab pengungkapan alamat periode waktu yang dibutuhkan vendor untuk memberikan patch setelah mereka tahu dari kerentanan. Tujuan utama dari pengungkapan yang bertanggung jawab adalah untuk meminimalkan waktu untuk mengurangi terjadinya serangan tersebut. Secara teori, jika vendor benar mengikuti prosedur patch pengungkapan yang bertanggung jawab, rilis patch akan terjadi sebelum topi hitam pengetahuan tentang kerentanan.Ini akan memungkinkan pelanggan bertanggung jawab untuk melindungi sistem mereka dari eksploitasi. Hal ini penting untuk dicatat bahwa jika komunitas topi hitam mulai menyerang sebelum pengungkapan publik kemudian timeline untuk pengungkapan publik memerlukan eskalasi segera.Ini akan memungkinkan pelanggan untuk mengambil tindakan pencegahan pada akhir administrasi sistem untuk melindungi terhadap kemungkinan eksploitasi.

Bagian pertama dari bagian ini membahas isu-isu etika bertanggung jawab pengungkapan dari sudut pandang pemerintah Amerika Serikat. Pada Desember 2002, Dennis Fisher dengan bantuan dari Institut SANS diminta masukan tentang The Fisher rencana. Menurut SANS Berita gigitan Daftar e-mail, The Fisher rencana muncul dalam beberapa hari setelah tanggal 2 Oktober 2002, ketika Richard Clarke mengatakan kepada dua ratus orang yang menghadiri SANS / FBI atas dua puluh kerentanan briefing di Washington, "mencari kerentanan. Jika Anda menemukan satu, memberitahu vendor, dan jika mereka tidak responsif, memberitahu pemerintah." Dennis berhak menunjukkan bahwa pemerintah adalah organisasi yang besar dan menghubungkan dengan orang yang tepat akan menjadi hampir mustahil.

Bagian kedua dari bagian ini membahas masalah-masalah dalam hubungan dengan forum diusulkan pengungkapan yang bertanggung jawab.Forum pengungkapan yang bertanggung jawab adalah cara yang berbeda pihak dapat perdebatan dan menengahi pengungkapan kerentanan mereka poin of view.Forum pengungkapan yang bertanggung jawab adalah upaya untuk mencapai sebuah kompromi antara semua pihak dalam debat pengungkapan. Individu dan bisnis baik berpartisipasi dalam forum pengungkapan, atau dianggap anggota komunitas topi hitam. Meskipun ini adalah pernyataan yang unik ketika Anda mempertimbangkan usulan bertanggung jawab pengungkapan lain, adalah komponen penting.Perlu ada penghalang untuk pengungkapan yang bertanggung jawab.Tanpa hukum perdata atau pidana untuk menghukum bertanggung jawab pengungkapan, pencatatan hitam mungkin pilihan yang efektif.

The Fisher Plan, Government Disclosure – Is it Necessary?

The Fisher Plan, pengungkapan pemerintah - Apakah diperlukan?

The Fisher Plan mengusulkan pemerintah pusat yang memegang tanggung jawab untuk reproduksi kerentanan, koordinasi Penjual, pelaporan menentukan batas waktu untuk perbaikan berdasarkan tingkat keparahan kerentanan, mengerahkan tekanan pada vendor untuk memperbaiki kelemahan dalam set timeline, koordinasi pengungkapan publik, dan mungkin mengeluarkan kompensasi finansial untuk penemu.Kelompok yang diusulkan dalam rencana Fisher akan menghadapi banyak tantangan. Apakah Anda merasa perlu dan etis untuk mengatur proses pengungkapan?

Conservative The Fisher Plan adalah sebuah proses yang menyambut dan diperlukan untuk pengungkapan kerentanan keamanan.Tanpa beberapa jenis peraturan, topi hitam akan selalu mengadakan keuntungan.Apa organisasi yang lebih baik untuk melakukan jenis pusat pelaporan daripada pemerintah, yang memiliki terpusat saluran komunikasi dan cukup dana untuk kegiatan keamanan. Itu tidak etis untuk gagal untuk memiliki proses seperti Fisher rencana yang sudah ditetapkan.

Liberal penemuan kerentanan sistem tak terelakkan.Orang-orang baik akan menemukan beberapa dan orang jahat akan menemukan yang lain. Hal ini dalam kepentingan terbaik mereka perusahaan dan individu yang tidak ingin dikaitkan dengan komunitas topi hitam untuk mengikuti kebijakan pengungkapan yang bertanggung jawab. Semua pihak yang berminat memperbaiki keadaan keamanan informasi akan datang bersama-sama dan kompromi untuk membangun sebuah tim ahli industri sehingga proses pengungkapan tidak jatuh kepada pemerintah. Terbaik di tangan swasta bisnis dan lainnya

perantara.

RINGKASAN

Terlepas dari Apakah Anda mendukung proses pemerintah atau swasta proses penanganan pengungkapan kerentanan keamanan, tidak ada keraguan bahwa komunitas TI harus menemukan cara untuk benar menangani masalah-masalah pengungkapan. Vendor harus menerima pemberitahuan dan klien harus menerima informasi kerentanan untuk perlindungan yang tepat mereka sistem informasi. Dalam

Akhirnya, Semua ini perlu dilakukan secara aman bijaksana.

The Responsible Disclosure Forum – Should One Be Created?

Forum pengungkapan yang bertanggung jawab – harus satu dibuat?

Di pusat bertanggung jawab pengungkapan forum adalah satu "kelompok inti."Kelompok inti ini harus lebih besar dan lebih beragam daripada kelompok individu saat ini dalam keberadaan untuk proses pengungkapan.Dengan sebuah forum pengungkapan yang bertanggung jawab, pengungkapan kerentanan baru semua pergi ke grup ini.Oleh karena itu, grup ini wields banyak kekuasaan atas bisnis.Tanggung jawab mereka termasuk prosedur preset yang memperoleh kepercayaan dari komunitas IT berikut.Kelompok inti akan bertindak sebagai koordinator dan akan bertanggung jawab untuk reproduksi, koordinasi komunikasi, dan tingkat keparahan penilaian. Penting bahwa kekuatan selain mereka sendiri-internal kebutuhan memotivasi vendor.Mempertahankan integritas dari grup "dipercaya" akan menimbulkan tantangan signifikan kedua praktis dan etika. Apakah Anda merasa industri IT siap untuk forum pengungkapan terpercaya inti, dan bahwa orang-orang dalam kelompok yang mewakili daerah bisnis yang berbeda akan bertindak dalam kepentingan terbaik dari semua pihak?

Conservative dalam dunia yang sempurna, memiliki sekelompok terpercaya optimal dan apa komunitas TI harus bekerja ke arah. Pada kenyataannya, kelompok ini memerlukan lapisan akuntabilitas untuk melindungi semua pihak. Kelompok kedua dapat mempertanggungjawabkan kelompok terpercaya dan menerima peringatan dini dengan informasi yang cukup untuk mempersiapkan pertahanan dan mendeteksi eksploitasi. Namun, sebuah kelompok tambahan menambah risiko dan banyak upaya harus diterapkan untuk tidak menerbitkan informasi teknis, script, atau alat-alat yang akan membantu berbakat script kiddies meluncurkan serangan.

Liberal A trusted group adalah solusi untuk Standardisasi proses pengungkapan kerentanan.Proses apapun, bahkan jika ia memiliki kelemahan, lebih baik daripada tidak ada proses sama sekali. Memang, tidak semua individu dapat dipercaya agar lebih baik dalam pikiran; Namun, industri IT siap dan sangat membutuhkan terpercaya inti pengungkapan forum.

RINGKASAN

Sudut pandang konservatif menambah kelemahan keseluruhan ide dengan memiliki kelompok kedua untuk menambahkan akuntabilitas Group yang terpercaya, yang akan memerlukan lebih banyak pekerjaan karena tim ini akan perlu untuk memastikan bahwa kerentanan informasi tidak prematur diungkapkan. Selain itu, mekanisme perlindungan perlu diletakkan di tempat untuk mencegah topi hitam dari infiltrasi kelompok kedua. Setiap pembesaran lingkaran kepercayaan sebelum patch memadai pengembangan dan pengujian akan meningkatkan risiko kebocoran informasi tetapi diperlukan dalam hal akuntabilitas. Liberal sudut pandangan bahwa harus ada sesuatu di tempat, bahkan jika itu tidak sempurna, jelas merupakan kesepakatan yang tidak dapat ditolak.

Chapter Summary

Ringkasan bab

Dalam bab ini kita membahas pertimbangan etis pengungkapan kerentanan keamanan. Topik pertama percakapan adalah apakah ketidak penyingkapan dianjurkan dalam keadaan apapun. Kami ditentukan bahwa jika mengungkapkan kerentanan sistem akan mengakibatkan kondisi keselamatan publik, itu tidak mungkin bijaksana untuk memilih untuk menjaga rahasia. Di sebagian besar keadaan lain, beberapa bentuk pengungkapan diperlukan.

Anda belajar bahwa pengungkapan penuh mengungkapkan semua rincian kerentanan termasuk rincian teknis dan skrip sebelum patch, yang memperbaiki kerentanan.

Aspek lain dari pengungkapan yang kita bahas adalah proses mengungkapkan informasi secara umum.Anda belajar bahwa pengungkapan publik ini mirip dengan pengungkapan penuh dengan satu pengecualian; Pengungkapan publik tidak akan menyertakan kode dieksploitasi.

Selanjutnya, kita menggali ke dalam dilema tugas etis untuk memperingatkan.Kami membahas apakah klien mempunyai hak untuk mengetahui kelemahan dalam solusi Penjual dan apakah penulis etis diperlukan untuk berkomunikasi kerentanan tersebut.

Berbeda dengan pengungkapan penuh, diskusi mengenai pengungkapan terbatas menyoroti bagaimana pengungkapan terbatas melindungi dari serangan berbahaya tetapi mungkin memiliki kelemahan yang melekat.Kelemahan-kelemahan ini terjadi karena terbatas pengungkapan mungkin tidak berlaku tekanan yang diperlukan untuk vendor untuk mengembangkan patch cukup mudah.

Hitam dan putih topi hacking dianggap berkaitan dengan proses pengungkapan kerentanan.Anda belajar mengapa orang yang menentang pengungkapan kerentanan keamanan penuh melakukannya karena mereka merasa bahwa penerbitan kerentanan sistem menyediakan pembukaan untuk black hat hacker untuk melakukan serangan berbahaya pada penjual produk. Berbeda dengan penyerang topi hitam, putih hat hacker membantu menemukan kerentanan untuk tujuan perlindungan.

Anda juga belajar bahwa bagian pembangunan penting untuk proses pengungkapan. Rentang waktu yang dibutuhkan untuk mengembangkan sebuah patch dari Kapan kerentanan ditemukan sangat bervariasi tergantung pada vendor dan kompleksitas sistem atau produk kelemahan.Ini mempengaruhi proses pengembangan yang jenis pengungkapan kerentanan keamanan paling efektif akan mengatasi masalah.

Bab ini diakhiri dengan pertimbangan rencana pengungkapan yang bertanggung jawab. Rencana pengungkapan yang bertanggung jawab tidak ada oleh karena itu, Bagian ini didasarkan pada studi di daerah untuk menciptakan terpercaya kelompok atau pemerintah mekanisme untuk menangani proses pengungkapan secara standar.

Frequently Asked Questions

Pertanyaan yang sering diajukan

Berikut pertanyaan yang sering diajukan, dijawab oleh para penulis buku ini,

dirancang untuk membuat Anda berpikir tentang keadaan etis Anda mungkin menghadapi

ketika melakukan pengungkapan kerentanan. Kecuali masalah hukum yang terlibat, maka

jawaban di FAQ tidak mungkin jawaban yang tepat untuk organisasi Anda. Beberapa

Jawaban mungkin lebih etis daripada yang lain, tapi respon yang benar adalah terserah Anda.

T: Apakah ada jenis kerentanan yang tidak pantas etis untuk mengungkapkan.

J: kerentanan yang berpotensi membahayakan publik, harus ditangani dengan hati-hati dan oleh pihak yang berwenang. Itu tidak etis untuk mengadopsi kebijakan ketidak penyingkapan untuk jenis kerentanan.

T: apa jenis tindakan defensif dapat diambil terhadap sistem kerentanan setelah pengungkapan penuh telah dibuat?

J: ada empat jenis tindakan defensif yang mungkin terjadi setelah pengungkapan penuh telah dibuat: 1. berkembang dan melaksanakan (tanda IDS untuk membolehkan Deteksi mengeksploitasi; 2. melaksanakan solusi sementara seperti mematikan Layanan rentan atau menghalangi lalu lintas di firewall; 3. administrator sistem dapat menggunakan kode dieksploitasi untuk memindai jaringan untuk rentan sistem atau untuk menguji kerentanan mungkin sistem yang telah ditambal; dan 4. Programmer produk dapat meninjau struktur Cacat dan upaya untuk menghindari situasi yang sama dalam pembangunan masa depan.

Q: Apakah etis sesuai untuk mengungkapkan kerentanan untuk tujuan publisitas atau untuk membuat pesaing terlihat buruk?

J: mengekspos kerentanan produk secara khusus untuk tujuan publisitas adalah etis tidak pantas karena menempatkan vendor dan klien resiko, terutama di kasus informasi kartu kredit. Jika Anda memilih untuk mengekspos kerentanan pesaing untuk publik, cobalah untuk melindungi klien mereka dari pribadi yang tidak perlu kerusakan.

Q: Apakah perbedaan antara pengungkapan terbatas dan pengungkapan penuh?

J: selama fase awal dari pengungkapan terbatas, akses ke rincian lengkap tentang kerentanan diberikan kepada sekelompok kecil orang.Kelompok ini beranggotakan berpotensi tiga pihak yang berbeda: pemberi informasi, vendor, dan mungkin Koordinator pihak ketiga. Tidak seperti penuh pengungkapan, proses pengungkapan terbatas tidak memberikan rincian lengkap teknis kerentanan pada saat akhir pengungkapan. Rilis rincian tersebut terjadi hanya ketika vendor perbaikan kelemahan sistem.

T: apa itu proses reverse engineering kode dalam kerentanan pengungkapan?

J: reverse engineering kode adalah proses mengambil executable dan berasal kode sumber dari yang dapat dieksekusi. Dalam proses pengungkapan kerentanan, ini dilakukan untuk mendeteksi dan memverifikasi kode kerentanan.

T: Mengapa adalah cepat-tambalan, yang tidak benar-benar diuji, penghalang bagi proses pengungkapan kerentanan.

A: dengan cepat berkembang patch yang tidak pergi melalui proses pengujian menyeluruh, dapat mendatangkan malapetaka yang lebih pada sistem daripada serangan berbahaya. Ketika sebuah patch adalah tidak benar diuji, hal itu mungkin mengandung bug atau kelemahan keamanan tambahan.