Bab Ringkasan
Dalam bab ini kita membahas pertimbangan etika pengungkapan kerentanan.
Topik pertama pembicaraan adalah apakah menjaga rahasia dianjurkan dalam setiap
keadaan.Kita ditentukan bahwa jika mengungkapkan kerentanan sistem akan menghasilkan
dalam kondisi keselamatan publik, tidak mungkin bijaksana untuk memilih menjaga rahasia. Di
keadaan paling lainnya, beberapa bentuk pengungkapan diperlukan.
Anda belajar bahwa pengungkapan penuh adalah mengungkapkan semua detail kerentanan
termasuk rincian teknis dan skrip sebelum patch, yang memperbaiki
kerentanan.

Aspek lain dari pengungkapan kita bahas adalah proses pengungkapan informasi
dalam manner.You publik mengetahui bahwa pengungkapan publik mirip dengan penuh
pengungkapan dengan satu pengecualian, pengungkapan publik tidak akan mencakup
dieksploitasi kode.
Selanjutnya, kita menggali ke dalam dilema tugas etis untuk dibahas warn.We
apakah klien memiliki hak untuk mengetahui kelemahan dalam solusi vendor dan
apakah penulis yang etis diperlukan untuk berkomunikasi kerentanan tersebut.
Berbeda dengan pengungkapan penuh, pembahasan mengenai pengungkapan terbatas disorot
bagaimana pengungkapan terbatas melindungi dari serangan berbahaya tetapi mungkin memiliki melekat
kelemahan weaknesses.These terjadi karena pengungkapan terbatas tidak mungkin menerapkan
diperlukan tekanan untuk vendor untuk mengembangkan patch cukup mudah.
Hacker topi hitam dan putih dianggap dalam kaitannya dengan kerentanan
pengungkapan process.You belajar mengapa mereka yang menentang pengungkapan kerentanan penuh
melakukannya karena mereka merasa bahwa penerbitan kerentanan sistem menyediakan
membuka untuk black hat hacker untuk melakukan serangan berbahaya pada produk vendor.
Berbeda dengan penyerang topi hitam, hacker topi putih membantu dalam menemukan kerentanan
untuk tujuan perlindungan.
Anda juga belajar bahwa pembangunan patch yang sangat penting untuk proses pengungkapan.
Rentang waktu yang dibutuhkan untuk mengembangkan patch dari ketika kerentanan itu
ditemukan sangat bervariasi tergantung pada vendor dan kompleksitas
produk atau sistem weakness.This proses pembangunan mempengaruhi jenis kerentanan
pengungkapan akan paling efektif mengatasi masalah tersebut.
Bab ini diakhiri dengan pertimbangan rencana pengungkapan yang bertanggung jawab.
Rencana pengungkapan yang bertanggung jawab tidak ada lagi, karena itu, bagian ini didasarkan pada
studi di bidang menciptakan kelompok dipercaya atau mekanisme pemerintah untuk
menangani proses pengungkapan secara standar.
www.syngress.com
102 Bab 3 • Kerentanan Pengungkapan
Q: Apakah ada jenis kerentanan yang tidak pantas etis untuk mengungkapkan.
A: Kerentanan yang berpotensi membahayakan masyarakat, harus ditangani dengan hati-hati
dan oleh pihak yang berwenang. Hal ini tidak etis untuk mengadopsi kebijakan
menjaga rahasia untuk jenis kerentanan.
Q: Apa jenis tindakan defensif dapat diambil terhadap kerentanan sistem
sekali pengungkapan penuh telah dibuat?
J: Ada empat jenis tindakan defensif yang mungkin terjadi setelah pengungkapan penuh
telah dibuat: 1. Mengembangkan dan menerapkan tanda tangan (IDS untuk memungkinkan
deteksi mengeksploitasi; 2. Menerapkan solusi sementara seperti
mematikan layanan rentan atau memblokir lalu lintas di firewall; 3.Setelah
administrator sistem dapat menggunakan kode dieksploitasi untuk memindai jaringan untuk rentan
sistem atau untuk menguji kerentanan kemungkinan sistem yang telah
ditambal, dan 4. Programmer produk dapat meninjau struktur
cacat dan berusaha untuk menghindari situasi yang sama dalam pembangunan masa depan.
Q: Apakah etis tepat untuk mengungkapkan kerentanan untuk tujuan publisitas
atau untuk membuat pesaing terlihat buruk?
A: Mengekspos kerentanan produk khusus untuk tujuan publisitas
etis tidak pantas karena menempatkan vendor dan klien beresiko, terutama di
kasus informasi kartu kredit. Jika Anda memilih untuk mengekspos kerentanan pesaing
kepada publik, mencoba untuk melindungi klien mereka dari pribadi yang tidak perlu
kerusakan.
Q: Apa perbedaan antara pengungkapan terbatas dan pengungkapan penuh?
A: Selama fase awal pengungkapan terbatas, akses ke rincian lengkap
kerentanan diberikan kepada sekelompok kecil kelompok terdiri individuals.This
www.syngress.com
Kerentanan Pengungkapan • Bab 3 103
Pertanyaan yang Sering Diajukan
Berikut Sering Diajukan, dijawab oleh penulis buku ini,
dirancang untuk membuat Anda berpikir tentang keadaan etika yang mungkin Anda hadapi
saat melakukan pengungkapan kerentanan. Kecuali masalah hukum yang terlibat, kemudian
jawaban di FAQ tidak mungkin menjadi jawaban yang tepat untuk organisasi Anda. Beberapa
jawaban mungkin lebih etis daripada yang lain, tapi respon yang benar adalah terserah Anda.
berpotensi dari tiga partai yang berbeda: Pengungkap, vendor, dan mungkin
pihak ketiga koordinator. Tidak seperti pengungkapan penuh, proses pengungkapan terbatas
tidak memberikan rincian teknis penuh dari kerentanan pada saat
akhir pengungkapan. Pelepasan tersebut rincian terjadi hanya ketika vendor perbaikan
kelemahan sistem.
Q: Bagaimana proses kode reverse engineering dalam kerentanan
pengungkapan?
A: Kode Reverse engineering adalah proses mengambil dieksekusi dan berasal
source code dari executable tersebut. Dalam proses pengungkapan kerentanan, ini
dilakukan untuk mendeteksi kerentanan dan memverifikasi kode.
T: Mengapa patch cepat, yang tidak benar-benar teruji, menjadi halangan untuk
kerentanan proses pengungkapan.
A: patch cepat berkembang yang tidak melalui proses pengujian menyeluruh,
mungkin mendatangkan malapetaka lebih pada sistem daripada serangan berbahaya. Ketika patch yang
tidak benar diuji, mungkin berisi bug atau kelemahan keamanan tambahan.
www.syngress

Keterbukaan Bertanggung Jawab
Forum - Satu Harus Dibuat?
Di tengah-tengah forum pengungkapan yang bertanggung jawab adalah "kelompok inti." Single core ini
Kelompok harus lebih besar dan lebih beragam daripada kelompok individu yang sedang
Keberadaan untuk pengungkapan process.With forum pengungkapan yang bertanggung jawab, pengungkapan
dari semua kerentanan baru pergi ke group.karena itu, kelompok ini wields banyak
kekuasaan atas tanggung jawab businesses.Their mencakup prosedur yang telah ditetapkan menyusul
yang mendapatkan kepercayaan dari kelompok inti TI community.The akan bertindak sebagai koordinator
dan akan bertanggung jawab untuk reproduksi, koordinasi komunikasi, dan tingkat keparahan
penilaian. Adalah penting bahwa pasukan selain kebutuhan internal mereka sendiri memotivasi
a vendor.Maintaining integritas dari kelompok "terpercaya" akan menimbulkan signifikan
menantang baik secara praktis maupun etis. Apakah Anda merasa industri TI siap untuk
dipercaya forum inti pengungkapan, dan bahwa individu-individu dalam kelompok itu yang mewakili
bidang bisnis yang berbeda akan bertindak dalam kepentingan terbaik dari semua pihak?
Konservatif Dalam dunia yang sempurna, memiliki kelompok dipercaya optimal dan
apa komunitas TI harus bekerja ke arah. Pada kenyataannya, kelompok ini membutuhkan
lapisan akuntabilitas untuk melindungi semua pihak. Kelompok kedua dapat menahan
dipercaya kelompok awal peringatan bertanggung jawab dan menerima dengan informasi yang cukup
untuk mempersiapkan pertahanan dan mendeteksi eksploitasi. Namun, sebuah kelompok tambahan
menambah risiko dan upaya yang cukup harus diterapkan untuk tidak mempublikasikan detail
Informasi teknis, script, atau alat-alat yang akan membantu script kiddies berbakat
dalam meluncurkan serangan.
www.syngress.com
100 Bab 3 • Kerentanan Pengungkapan
Sebuah kelompok liberal dipercaya adalah solusi yang layak untuk standarisasi
kerentanan pengungkapan proses process.Any, bahkan jika ia memiliki kelemahan, adalah
lebih baik daripada tidak ada proses sama sekali. Memang, tidak semua orang dapat dipercaya untuk
menjaga kebaikan yang lebih besar dalam pikiran, namun, industri TI siap dan sangat
membutuhkan forum inti pengungkapan dipercaya.
RINGKASAN
Titik pandang konservatif menambahkan kelemahan gagasan secara keseluruhan
memiliki kelompok kedua untuk menambah akuntabilitas kepada kelompok dipercaya, yang
akan memerlukan lebih banyak bekerja karena tim ini akan perlu untuk memastikan bahwa kerentanan
Informasi ini tidak diungkapkan prematur. Selain itu, perlindungan
Mekanisme harus diletakkan di tempat untuk mencegah topi hitam dari infiltrasi
dari kelompok kedua. Setiap pembesaran lingkaran kepercayaan sebelum
Patch pengembangan dan pengujian yang memadai akan meningkatkan risiko informasi
kebocoran tetapi diperlukan dalam hal akuntabilitas. Liberal
pandangan bahwa harus ada sesuatu di tempat, bahkan jika itu tidak
sempurna, pasti sebuah kesepakatan yang tidak dapat dipungkiri.

Bertanggung jawab Pengungkapan Rencana
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. Sebuah berbahaya
Serangan dapat terjadi kapan saja, namun, pengungkapan yang bertanggung jawab membahas
periode waktu yang dibutuhkan vendor untuk menyediakan patch setelah mereka tahu dari kerentanan.
Tujuan utama dari pengungkapan yang bertanggung jawab adalah untuk meminimalkan periode itu
waktu untuk mengurangi terjadinya serangan. Secara teori, jika vendor benar berikut
prosedur pengungkapan yang bertanggung jawab patch, rilis patch akan terjadi sebelum
pengetahuan topi hitam dari kerentanan.ini akan memungkinkan pelanggan bertanggung jawab
untuk melindungi sistem mereka dari eksploitasi. Penting untuk dicatat bahwa jika black
hat masyarakat mulai serangan sebelum pengungkapan publik maka timeline untuk
pengungkapan publik membutuhkan escalation.ini langsung akan memungkinkan pelanggan untuk mengambil
tindakan pencegahan pada akhir administrasi sistem untuk melindungi terhadap kemungkinan
eksploitasi.
Bagian pertama dari bagian ini membahas masalah-masalah etika pengungkapan yang bertanggung jawab
dari sudut pandang pemerintah AS. Pada bulan Desember 2002, Dennis
Fisher dengan bantuan dari SANS Institute meminta masukan tentang Rencana Fisher.
Menurut Berita SANS daftar Bites e-mail, Rencana Fisher muncul pada hari-hari
mengikuti 2 Oktober, 2002 ketika Richard Clarke mengatakan dua ratus orang
menghadiri SANS / FBI Top Twenty pengarahan Kerentanan di Washington,
www.syngress.com
98 Bab 3 • Kerentanan Pengungkapan
"Carilah 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
hampir mustahil.
Bagian kedua dari bagian ini membahas masalah-masalah dalam hubungan dengan yang diusulkan
pengungkapan forum.The forum pengungkapan yang bertanggung jawab bertanggung jawab adalah sarana
dimana berbagai pihak dapat berdebat dan memediasi pengungkapan kerentanan mereka
poin forum pengungkapan melihat.Drive bertanggung jawab adalah upaya untuk mencapai kompromi
antara semua pihak dalam debat pengungkapan. Individu dan bisnis baik
berpartisipasi dalam forum pengungkapan, atau dianggap anggota topi hitam
masyarakat. Meskipun ini merupakan pernyataan yang unik ketika Anda mempertimbangkan lainnya
proposal pengungkapan yang bertanggung jawab, itu adalah component.There penting perlu
penghalang untuk sipil disclosure.Without tidak bertanggung jawab atau hukum pidana untuk menghukum
pengungkapan yang tidak bertanggung jawab, daftar hitam publik dapat menjadi pilihan yang efektif.
The Fisher Rencana,
Pengungkapan pemerintah - Apakah Diperlukan?
Rencana Fisher mengusulkan pusat pemerintahan pelaporan yang memegang tanggung jawab
untuk kerentanan reproduksi, koordinasi vendor, menentukan batas waktu untuk
memperbaiki didasarkan pada keparahan dari kerentanan, melakukan tekanan pada vendor
untuk memperbaiki kerentanan dalam waktu yang ditetapkan, koordinasi melaporkan keterbukaan informasi, dan
mungkin mengeluarkan kompensasi finansial kepada kelompok discoverer.The diusulkan dalam
Rencana Fisher akan menghadapi banyak tantangan. Apakah Anda merasa perlu dan etis
untuk mengatur proses pengungkapan?
Konservatif Rencana Fisher adalah proses diterima dan diperlukan untuk
kerentanan disclosure.Without beberapa jenis regulasi, topi hitam akan
selalu memegang organisasi advantage.What lebih baik untuk melakukan ini jenis
melaporkan pusat dari pemerintah, yang memiliki saluran terpusat
komunikasi dan pendanaan yang cukup untuk kegiatan keamanan. Ini tidak etis
gagal untuk memiliki proses seperti Rencana Fisher sudah diatur di tempat.
Penemuan Liberal kerentanan sistem adalah orang-orang baik takterelakan.The
akan menemukan beberapa dan orang jahat akan menemukan orang lain. Hal ini dalam
terbaik kepentingan perusahaan-perusahaan dan individu yang tidak ingin berhubungan
dengan komunitas topi hitam untuk mengikuti pengungkapan yang bertanggung jawab
kebijakan. Semua pihak yang tertarik dalam meningkatkan keadaan keamanan informasi
akan harus datang bersama-sama dan kompromi untuk membangun sebuah tim
www.syngress.com
Kerentanan Pengungkapan • Bab 3 99
pakar industri sehingga proses pengungkapan tidak jatuh ke pemerintah.
Cara terbaik adalah di tangan bisnis sektor swasta dan lainnya
perantara.
RINGKASAN
Terlepas dari apakah Anda mendukung proses pemerintah atau swasta proses
untuk menangani pengungkapan kerentanan, tidak ada keraguan bahwa TI
masyarakat harus menemukan cara untuk benar menangani masalah pengungkapan.
Vendor harus menerima pemberitahuan dan klien harus menerima kerentanan
Informasi untuk perlindungan yang tepat dari sistem informasi mereka. Di
akhirnya, semua ini perlu terjadi secara aman bijaksana.

Menggabungkan Perbaikan Sistem dengan
Patch Keamanan - Menambahkan Risiko Lebih?
Satu masalah dengan pengungkapan penuh adalah lomba untuk menciptakan patch yang perbaikan
keamanan issue.When menangani kerentanan diungkapkan, beberapa perusahaan sering
menggabungkan perbaikan sistem dengan keamanan patches.You sebagai administrator sistem menemukan
proses ini mempersulit memperbaiki kerentanan karena dapat mempengaruhi daerah lain
sistem Anda. Perbaikan sistem tambahan ditambahkan ke patch menimbulkan masalah baru
muncul, yang tidak dapat dengan mudah diisolasi. Apakah etis untuk menanggapi pengungkapan penuh
dengan menggabungkan perbaikan sistem dengan patch kerentanan? Selain itu, kadang-kadang
patch dikembangkan begitu cepat yang mengandung kesalahan dan crash sistem itu
dirancang untuk memperbaiki. Apakah etis untuk menanggapi pengungkapan penuh dengan menerbitkan cepat
patch, di mana patch pengujian yang tepat tidak terjadi karena pengungkapan penuh?
Sistem patch untuk kerentanan diungkapkan konservatif harus
independen dari setiap perbaikan sistem tambahan atau upgrade. Kerentanan keamanan
memerlukan solusi yang efektif dilakukan dengan cara yang paling aman dicapai.
Rumitnya kerentanan dengan perbaikan sistem tambahan adalah cara tidak etis
untuk menangani patches.This keamanan ini terutama berlaku dalam kasus menciptakan
kerentanan patch yang terlalu cepat tanpa pengujian yang tepat dari patch pada
operasi system.There selalu bahaya meningkatnya kerusakan lebih
kemudian mengatasi masalah. Pengungkapan penuh bukan alasan untuk cepat
patch yang menyebabkan masalah sistem muncul.
Salah satu Liberal hasil pengungkapan penuh adalah perbaikan cepat yang mungkin tidak efektif
atau merusak sistem mereka mencoba untuk address.This hanya bagian
dari realitas proses pengungkapan penuh. Ini menekan vendor untuk membuat
www.syngress.com
Kerentanan Pengungkapan • Bab 3 97
langsung respon bahkan jika mereka tidak secara teknis siap untuk melakukan so.There
yang salah dengan patch kerentanan menggabungkan dengan tambahan apa-apa
minor sistem patch selama mereka tidak menyebabkan masalah.
RINGKASAN
Mengenai isu menggabungkan perbaikan dengan patch kerentanan, beberapa
dapat mempertimbangkan risiko tambahan menambah masalah awal. Lainnya
mungkin merasa bahwa menyediakan perbaikan tambahan tidak menyebabkan masalah dan
mungkin tidak merasa ini adalah masalah etis. Selain itu, ketika patch tidak
aptly diuji, masalah yang timbul. Ini mungkin merupakan konsekuensi negatif
proses pengungkapan penuh.

Patch Pengembangan
Selama proses mendeteksi dan memperbaiki kerentanan produk, koreksi
Tahap dimulai dengan pengembangan patch. Pengembangan patch adalah langkah penting
ketika menangani berbagai produk vulnerabilities.The dari waktu yang dibutuhkan untuk melihat
hasil patch dari kerentanan penemuan sangat bervariasi tergantung pada
vendor dan kompleksitas kelemahan produk atau sistem. Dalam beberapa kasus,
Pengembangan Patch dapat mengambil banyak waktu jika cacat yang melekat pada
struktur vendor product.The mungkin juga harus mengatasi alat serupa lainnya,
yang memiliki masalah yang sama dalam line.This produk mereka terutama
kasus ketika vendor mengembangkan produk memanfaatkan perpustakaan kode pusat.
Berikut ini adalah contoh yang sangat baik dari kompleksitas perkembangan patch di
kaitannya dengan pengungkapan process.We mendiskusikan masalah etika dengan Sederhana
www.syngress.com
Kerentanan Pengungkapan • Bab 3 95
Network Management Protocol (SNMP) vulnerabilities.This bagian juga
alamat perangkap rilis patch yang termasuk patch yang menggabungkan sistem
perbaikan, dan patch cepat yang crash sistem yang seharusnya untuk memperbaiki.
Mengambil Pasar
Keuntungan - Haruskah Anda Berkomunikasi?
Anda menemukan kerentanan dalam produk yang Anda kembangkan memanfaatkan SNMP.This
Masalah akibatnya ada di produk lain memanfaatkan SNMP. Pemberitahuan
vendor tambahan dan pelepasan rincian kerentanan tersebut diperlukan untuk
benar menguji produk mereka untuk kelemahan ini. Namun, jika Anda tidak memberitahu
vendor lain dan memperbaiki masalah dalam perangkat lunak Anda, Anda dapat mempublikasikan
kesalahan dan mendapatkan keuntungan pasar. Apakah etis untuk gagal untuk mengungkapkan informasi
sekitar satu kelemahan SNMP jika akan memberikan keuntungan pasar?
Konservatif Keterlibatan beberapa vendor dapat mengakibatkan kebingungan
dan miskomunikasi terutama pada isu yang mempengaruhi pesaing.
Karena hal yang benar untuk dilakukan adalah mengkomunikasikan kerentanan SNMP,
setiap upaya harus dilakukan untuk menjaga semua tindakan terkoordinasi. Jika satu vendor
rilis informasi kerentanan prematur, para pelanggan dari
vendor yang tersisa akan dibiarkan terbuka.
Para perusahaan harus bekerja sama untuk menguji semua patch dan memastikan mereka
yang afektif untuk berbagai produk memanfaatkan SNMP. Perbedaan dalam lingkungan
dan konfigurasi sistem dapat menyebabkan patch untuk memiliki sisi negatif
efek. Setelah patch sukses semua produk menggunakan SNMP
akan aman.
Pengetahuan Liberal masalah dalam sumber daya bersama oleh vendor bersaing
memberikan keunggulan bisnis. Menggunakannya untuk keuntungan Anda. Mencari
masalah dengan sumber daya bersama dan menangani itu dalam produk Anda adalah
prerogative.You Anda tidak etis diperlukan untuk berbagi informasi ini untuk
setiap reason.You logis bisa memastikan pesaing Anda tidak akan membuat
bahwa komunikasi kepada Anda. Memanfaatkan kesempatan ini untuk meninggalkan kompetisi
dalam debu.
www.syngress.com
96 Bab 3 • Kerentanan Pengungkapan
RINGKASAN
Pilihan etis yang jelas untuk gambar yang lebih besar adalah untuk berkomunikasi
kerentanan serius dalam kode SNMP untuk semua orang yang menggunakannya dalam produk mereka.
Namun, kebanyakan orang tidak mendasarkan etika pribadi mereka pada
kebaikan yang lebih besar bagi umat manusia, mereka mendasarkan mereka pada hal-hal kecil dan pribadi
hubungan. Beberapa merasa itu bukan tanggung jawab etis mereka untuk berkomunikasi
suatu kelemahan SNMP untuk pesaing mereka. Mereka bahkan banyak
mempertimbangkan jenis komunikasi pelanggaran loyalitas perusahaan.

Pemerintah pada
Hacker - Haruskah Anda Balik Kode?
Keamanan dunia maya departemen 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 para pedagang dan
government.This adalah kontras dengan apa yang beberapa profesional TI merasa bahwa mereka
memerlukan ketika menjaga sistem integritas pemerintah mereka intact.The memungkinkan keamanan
profesional untuk menemukan kerentanan, namun mengkomunikasikan bahwa reverse engineering
kode yang dilakukan oleh orang lain selain keamanan komputer profesional adalah untuk
purposes.This bermoral berarti bahwa kecuali jika Anda adalah seorang ahli keamanan informasi
Anda tidak dapat melihat terlalu dalam ke produk vendor untuk menemukan kerentanan, sehingga
menghalangi kemampuan Anda untuk menerapkan perlindungan yang diperlukan untuk sistem di bawah Anda
jawab. Apakah bermoral untuk membalikkan kode engineer jika tujuan Anda adalah untuk melindungi
sistem Anda mengelola atau bekerja dengan?
www.syngress.com
94 Bab 3 • Kerentanan Pengungkapan
Kebalikan kode rekayasa konservatif harus tetap dalam ranah
keamanan informasi profesi dan bukan di tangan administrator sistem
atau programmer. Hal ini tidak etis untuk membalikkan kode insinyur dari vendor
bahkan jika tujuan Anda adalah untuk menemukan kerentanan dan melindungi sistem Anda sendiri
dari seperti kelemahan produk.
Liberal Sistem administrator dan pengembang perlu diingat
integritas produk dan lingkungan alam di bawah tanggung jawab mereka
dan data sensitif dalam environments.There mereka adalah apa-apa
salah dengan menjamin perlindungan informasi pelanggan kartu kredit jika
Anda memiliki alasan untuk percaya bahwa produk perangkat lunak yang Anda gunakan untuk memproses
transaksi kartu kredit bukanlah pilihan yang paling etis secure.The dalam keadaan demikian
adalah untuk melakukan reverse engineering alat vendor, menemukan kelemahan, laporan
ke vendor, dan menerapkan langkah-langkah perlindungan pada sistem Anda untuk mencegah
penyalahgunaan kerentanan ini. Kegagalan untuk melakukannya akan menjadi tidak etis.
RINGKASAN
Masalah ini sangat sulit untuk memilah-milah karena kompleksitasnya. Di
satu tangan, instansi pemerintah menyatakan bahwa reverse engineering produk
Kode tidak bermoral untuk beberapa profesi teknologi untuk melakukan; pada
Sebaliknya, gagal perlindungan yang memadai dari informasi pelanggan
tanpa keraguan tidak etis.

 Black and White Hat Hacker
Orang-orang yang menentang pengungkapan kerentanan full melakukannya karena mereka merasa bahwa
penerbitan kerentanan sistem menyediakan pembukaan untuk "black hat hacker" untuk
melakukan serangan berbahaya pada produk vendor. Mengungkap rincian sistem
kelemahan hacker bahan bakar dengan pengetahuan yang mereka butuhkan untuk menyalahgunakan kelemahan-kelemahan.
Selain itu, "hacker topi putih" yang bertanggung jawab untuk menemukan kerentanan,
telah menetapkan sendiri masalah moral untuk mengatasi saat reverse engineering
produk untuk tujuan perlindungan kerentanan menemukan.
Bagian ini membahas cara-cara yang hacker menyalahgunakan pengungkapan penuh
proses. Hal ini juga membahas dampak etis dari penyalahgunaan tersebut, baik kepada
hacker dan mereka yang memberikan pengungkapan penuh. Selanjutnya, kita menggali ke topi putih
hacker dan apakah produk reverse engineering etis dari sudut
melihat perlindungan sistem.
Hacker Memanfaatkan Kerentanan
Pengungkapan - Apakah Pengungkapan Kendali Diperlukan?
Anda bekerja untuk sebuah perusahaan keamanan informasi dan mengungkap bukti bahwa
topi hitam adalah memanfaatkan vulnerabilities.You sistem operasi yang signifikan tahu
bahwa cara untuk menghindari jenis eksploitasi adalah jika bisnis tidak memberikan penuh
pengungkapan. Dari sudut pandang keamanan informasi pandang, Anda bisa berdebat yang penuh
pengungkapan hacker bahan bakar dan dengan demikian tidak etis?
Konservatif Hal yang paling penting bagi para profesional keamanan informasi
adalah sistem pencegahan integrity.The mengungkap kelemahan sistem
terhadap serangan berbahaya adalah priority.Anything pertama yang berpotensi dapat menghasilkan
serangan membutuhkan kerahasiaan dan perlindungan. Meskipun disclowww penuh.
syngress.com
Kerentanan Pengungkapan • Bab 3 93
lakukannya dalam beberapa kasus, dapat mempercepat proses melindungi kerentanan,
mereka adalah kewajiban dalam diri mereka kepada petugas keamanan informasi.
Penerbitan kode serangan hanya tidak etis dan memberikan ide-ide baru untuk masa depan
serangan. Ini menyediakan suatu pustaka dari sumber daya untuk coders berbahaya.
Pengungkapan publik liberal diperlukan bagi pelanggan untuk membela mereka
sumber daya. Bahkan jika penyerang berbahaya tidak menyadari kelemahan keamanan
dan ide-ide kode berbahaya sudah, mereka akan segera menyadari mereka
sendiri sehingga tidak menyediakan bahan bakar untuk pekerjaan. Itu hampir mustahil
untuk memberikan keamanan yang efektif untuk sistem ketika keamanan informasi
petugas menerima informasi jelas mengenai kerentanan sistem.
RINGKASAN
Ini perdebatan tentang pengungkapan penuh dipanaskan dan tidak ada jawaban yang tepat.
Kedua sudut pandang memiliki kekuatan dan kelemahan. Namun, karena
resistensi vendor untuk memperbaiki kerentanan keamanan, jalan lebih mungkin
informasi yang paling profesional keamanan akan mengambil adalah bahwa pengungkapan penuh.
Pasukan pengungkapan vendor untuk menyediakan patch untuk keamanan yang dikenal penuh
kelemahan. Jika vendor yang lebih cepat pada kaki mereka ketika menanggapi
kelemahan dalam produk mereka, pengungkapan penuh tidak akan menjadi suatu keharusan
dan argumen akan terlihat sangat berbeda.

sushahnya minta maaf gak bisa menterjemahkan bahasa dengan baik.,,google translate kurang sempurna bikin kerancuan ,..tapi tetep aja bantu dikit

allhamdulillah wdah mulai bulan oktober ....
tidak terasa kuliah sudah sebulan ,
berharap makin nambah ilmu dan wawasan..
ya allah berikan aku kesabran dalam menuntut ilmu
banyak jalan yang susah ,,
namun aku ingin sukses atau setidaknya tidak dibodohin orang bodoh"""