it-swarm-id.com

Sumber Terbuka vs Sistem Sumber Tertutup

Pemahaman saya adalah bahwa sistem sumber terbuka umumnya diyakini lebih aman daripada sistem sumber tertutup .

Alasan untuk mengambil pendekatan, atau kombinasi dari mereka, termasuk: norma budaya, keuangan, penentuan posisi hukum, keamanan nasional, dll - yang semuanya dalam beberapa cara berhubungan dengan pandangan budaya tentang efek memiliki sistem itu sumber terbuka atau tertutup.

Salah satu masalah utama adalah keamanan. Posisi umum terhadap sistem sumber terbuka adalah bahwa penyerang dapat mengeksploitasi kelemahan dalam sistem jika diketahui. Posisi umum terhadap sistem sumber tertutup adalah bahwa kurangnya kesadaran merupakan tindakan keamanan yang lemah; biasa disebut sebagai keamanan melalui ketidakjelasan .

Pertanyaannya adalah, apakah sistem open source rata-rata lebih baik untuk keamanan daripada sistem sumber tertutup? Jika memungkinkan, harap sebutkan analisis dalam sebanyak mungkin industri, misalnya: perangkat lunak , militer , pasar keuangan , dll.

Pertanyaan ini adalah Pertanyaan Keamanan IT of the Week .
Baca tanggal 25 Mei 2012 entri blog untuk lebih jelasnya atau kirim milik Anda sendiri Pertanyaan dalam Pekan.

53
blunders

Gagasan bahwa perangkat lunak sumber terbuka secara inheren lebih aman daripada perangkat lunak sumber tertutup - atau gagasan sebaliknya - adalah omong kosong. Dan ketika orang mengatakan sesuatu seperti itu seringkali hanya FUD dan tidak memajukan diskusi secara berarti.

Untuk alasan tentang ini Anda harus membatasi diskusi untuk proyek spesifik. Sepotong perangkat lunak yang menggaruk gatal tertentu, dibuat oleh tim tertentu, dan memiliki target audiens yang jelas. Untuk kasus spesifik seperti itu, dimungkinkan untuk mempertimbangkan apakah open source atau closed source akan memberikan manfaat terbaik bagi proyek.

Masalah dengan pitching semua "open source" versus semua "open source" implementasi adalah bahwa seseorang tidak hanya membandingkan lisensi. Dalam prakteknya, open source adalah disukai oleh upaya sukarela harus, dan sumber tertutup paling umum dalam upaya komersial. Jadi kami sebenarnya membandingkan:

  • Lisensi.
  • Akses ke kode sumber.
  • Sangat berbeda struktur insentif , nirlaba versus bersenang-senang.
  • Situasi tanggung jawab hukum yang sangat berbeda.
  • Ukuran tim dan keterampilan tim yang berbeda, dan sangat bervariasi.
  • dll.

Untuk mencoba menilai bagaimana semua ini bekerja untuk keamanan di semua perangkat lunak yang dirilis sebagai sumber terbuka/tertutup rusak. Itu menjadi pernyataan pendapat, bukan fakta.

50
Jesper M

Dikelola perangkat lunak lebih aman daripada perangkat lunak yang tidak. Upaya pemeliharaan menjadi, tentu saja, relatif terhadap kompleksitas perangkat lunak tersebut dan jumlah (dan keterampilan) orang yang melihatnya. Teori di balik sistem open source menjadi lebih aman adalah bahwa ada "banyak mata" yang melihat kode sumber. Tetapi ini sangat tergantung pada popularitas sistem.

Sebagai contoh, pada tahun 2008 ditemukan di OpenSSL beberapa buffer overflows , beberapa di antaranya mengarah pada eksekusi kode jarak jauh. Bug ini telah berbohong dalam kode selama beberapa tahun. Jadi, meskipun OpenSSL adalah opensource dan memiliki basis pengguna yang besar (ini, bagaimanapun, perpustakaan SSL utama yang digunakan untuk situs web HTTPS), jumlah dan keahlian auditor kode sumber tidak cukup untuk diatasi kompleksitas inheren ASN.1 decoding (bagian dari OpenSSL tempat bug bersembunyi) dan kode sumber OpenSSL (terus terang, ini bukan kode sumber C yang paling mudah dibaca yang pernah ada).

Sistem sumber tertutup memiliki, rata-rata, lebih sedikit orang yang melakukan T&J. Namun, banyak sistem sumber tertutup memiliki bayar pengembang dan penguji, yang dapat berkomitmen untuk pekerjaan penuh waktu. Ini tidak benar-benar melekat pada pertanyaan buka/tutup; beberapa perusahaan mempekerjakan orang untuk mengembangkan sistem opensource, dan, bisa dibayangkan, seseorang dapat menghasilkan perangkat lunak sumber tertutup secara gratis (ini relatif umum dalam kasus "freewares" untuk Windows). Namun, masih ada korelasi yang kuat antara membayar penguji, dan menjadi sumber tertutup (korelasi tidak menyiratkan hubungan sebab akibat, tetapi ini tidak berarti bahwa korelasi juga harus diabaikan).

Di sisi lain, menjadi sumber tertutup membuatnya lebih mudah untuk menyembunyikan masalah keamanan, yaitu buruk, tentu saja.

Ada contoh sistem sumber terbuka dan tertutup, dengan banyak atau sangat sedikit masalah keamanan. Opensource * Sistem operasi BSD ( FreeBSD , NetBSD dan OpenBSD , dan beberapa lainnya) memiliki rekam jejak yang sangat baik berkaitan dengan keamanan. Begitu juga Solaris, bahkan ketika itu adalah sistem operasi sumber tertutup. Di sisi lain, Windows memiliki (memiliki) reputasi buruk dalam hal ini.

Ringkasan: menurut saya, ide "opensource menyiratkan keamanan" terlalu dibesar-besarkan. Yang penting adalah waktu (dan keterampilan) yang digunakan untuk melacak dan memperbaiki masalah keamanan, dan ini sebagian besar ortogonal untuk pertanyaan keterbukaan sumber. Namun, Anda tidak hanya menginginkan sistem yang aman, Anda juga ingin sistem yang Anda positif tahu aman (tidak dirampok itu penting, tetapi mampu tidur di malam hari juga). Untuk peran itu, sistem opensource memiliki sedikit keuntungan: lebih mudah untuk diyakinkan bahwa tidak ada lubang keamanan yang disembunyikan dengan sengaja ketika sistem open source. Tapi kepercayaan adalah hal yang meluap-luap, seperti yang ditunjukkan dengan tragisomedi baru-baru ini di sekitar diduga backdoors di OpenBSD (sejauh yang saya tahu, itu ternyata menjadi ikan haring merah, tetapi, secara konsep, saya tidak bisa yakin kecuali saya periksa sendiri kodenya).

37
Thomas Pornin

Saya pikir yang paling mudah, paling sederhana dalam hal ini adalah rekayasa perangkat lunak. Argumen biasanya mengikuti: open source perangkat lunak lebih aman karena Anda dapat melihat sumbernya !

Apakah Anda memiliki pengetahuan rekayasa perangkat lunak untuk memahami kernel top down? Tentu, Anda dapat melihat driver seperti itu, tetapi apakah Anda memiliki pengetahuan lengkap tentang apa yang sebenarnya terjadi dengan mengatakan "ah ya, pasti ada bug di sana"?

Berikut ini contoh yang menarik: belum lama ini bug null pointer dereference muncul di salah satu kernel beta yang merupakan hal yang cukup besar, ditemukan oleh pria dari grsecurity (patch PaX):

Itu diperkenalkan dalam sepotong kode seperti ini:

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

dan pointer == NULL check dioptimalkan oleh kompiler, dengan benar - karena pointer nol tidak dapat disereferensikan ke struct yang berisi anggota, tidak masuk akal jika pointer dalam fungsi tersebut menjadi null. Kompiler kemudian menghapus centang yang diharapkan pengembang ada di sana.

Ergo, vis a vis, secara bersamaan, kode sumber untuk proyek sebesar itu mungkin terlihat benar - tetapi sebenarnya tidak.

Masalahnya adalah tingkat pengetahuan yang dibutuhkan di sini. Anda tidak hanya harus cukup fasih dengan (dalam hal ini) C, Assembly, subsistem kernel tertentu, segala sesuatu yang sejalan dengan pengembangan kernel tetapi Anda juga perlu memahami apa yang dilakukan kompiler Anda.

Jangan salah paham, saya setuju dengan Linus bahwa dengan mata yang cukup, semua bug dangkal. Masalahnya adalah pengetahuan di otak di belakang mata. Jika Anda membayar 30 anak jagoan untuk mengembangkan produk Anda tetapi proyek sumber terbuka Anda hanya memiliki 5 orang yang memiliki pengetahuan nyata tentang basis kode, maka jelas versi sumber tertutup memiliki kemungkinan lebih besar untuk lebih sedikit bug, dengan asumsi kompleksitas yang relatif sama .

Jelas, ini juga untuk proyek yang diberikan sementara dari waktu ke waktu, seperti yang dibahas oleh Thomas Pornin.

Pembaruan diedit untuk menghapus referensi ke gcc yang salah, karena sebenarnya tidak.

17
user2213

Saya pikir tempat yang paling banyak digunakan untuk membedakan antara sumber tertutup dan open cukup didefinisikan dengan baik. Banyak dari mereka yang terdaftar di sini, keduanya memiliki pendukung mereka. Tidak mengherankan para pendukung untuk Sumber Tertutup adalah mereka yang menjualnya. Para pendukung Open Source juga menjadikannya bisnis yang bagus dan rapi (di luar beberapa yang menganggapnya sebagai agama.)

Gerakan Pro Open Source berbicara kepada dasar-dasar, dan ketika datang ke keamanan secara umum di sini adalah poin yang paling sesuai dengan diskusi:

  1. Premis Kustomisasi
  2. Premis Manajemen Lisensi
  3. Premis Format Terbuka
  4. Premis Banyak Mata
  5. Premis Perbaikan Cepat

Jadi dengan merinci ini berdasarkan premis, saya pikir dua yang terakhir telah dibahas secara ringkas oleh orang lain di sini, jadi saya akan meninggalkan mereka sendirian.

  1. Premis Kustomisasi
    Sebagaimana berlaku untuk keamanan, Customization Premise memberi perusahaan yang mengadopsi perangkat lunak kemampuan untuk membangun kontrol keamanan tambahan ke platform yang ada tanpa harus mengamankan lisensi atau meyakinkan vendor untuk memperbaiki sesuatu dari mereka. Ini memberdayakan organisasi yang perlu, atau melihat celah, untuk meningkatkan keamanan keseluruhan produk. SELinux adalah contoh sempurna, Anda bisa berterima kasih pada NSA untuk mengembalikannya ke komunitas.

  2. Premis Manajemen Lisensi
    Seringkali terungkap bahwa jika Anda menggunakan teknologi F/OSS Anda tidak perlu mengelola lisensi teknologi dengan pihak ketiga (atau jika Anda melakukannya jauh lebih sedikit.), Dan ini bisa benar sepenuhnya dari Open. Sumber ekosistem. Tetapi banyak lisensi (terutama GPL) memaksakan persyaratan pada distributor, dan sebagian besar lingkungan dunia nyata adalah campuran heterogen teknologi tertutup dan sumber terbuka. Jadi, meskipun pada akhirnya mengurangi pengeluaran perangkat lunak, ketersediaan sumber dapat menyebabkan beberapa perusahaan melanggar lisensi OSS dengan menjaga sumber pribadi ketika mereka memiliki kewajiban untuk melepaskan sumber. Ini pada akhirnya dapat mengubah premis manajemen lisensi menjadi kewajiban (yang merupakan argumen sumber tertutup terhadap lisensi seperti GPL.)

  3. The Open Format Premise
    Ini adalah yang besar, dan yang saya cenderung setuju jadi saya akan membuatnya singkat agar tidak mengabar. 30 Tahun dari sekarang saya ingin dapat membuka file yang saya tulis. Jika file "dilindungi" menggunakan kontrol DRM eksklusif dan perangkat lunak yang saya butuhkan untuk mengaksesnya tidak lagi dijual, kesulitan dalam mengakses konten saya sendiri telah meningkat secara dramatis. Jika ada format yang digunakan untuk membuat dokumen saya yang terbuka, dan tersedia dalam produk open source sejak 30 tahun yang lalu, saya mungkin dapat menemukannya dan secara legal dapat menggunakannya. Beberapa perusahaan melompat pada kereta band "Open Format" tanpa melompat pada kereta musik Open Source, jadi argumen ini menurut saya cukup bagus.

Ada Keenam premis yang saya tidak daftar, karena tidak dibahas dengan baik. Saya cenderung terjebak di dalamnya (sebut saja paranoia.) Saya pikir premis keenam adalah bulu di tutup departemen pertahanan di seluruh dunia. Itu dieja ke dunia ketika sebagian dari sumber windows 2000 bocor.

Premis Pertanggungjawaban Sumber Tertutup
Jika sebuah perusahaan telah menghasilkan perpustakaan kode sumber tertutup atau API melalui beberapa rilis selama beberapa dekade, kelompok-kelompok kecil individu telah memiliki akses ke sumber itu selama produksi itu. Beberapa di antaranya adalah kelompok audit pihak ketiga, dan pengembang yang telah pindah ke perusahaan/pemerintah lain. Jika kode itu cukup statis, untuk mempertahankan kompatibilitas sebagai premis manfaat sumber tertutup, sehingga beberapa kelemahan bisa tidak diumumkan selama bertahun-tahun. Mereka yang memiliki akses ke sumber tertutup itu memiliki kebebasan untuk menjalankan alat analisis kode terhadapnya untuk mempelajari kelemahan ini, repositori bug dari toko pengembangan perangkat lunak itu penuh dengan bug "minor" yang dapat mengarah pada eksploitasi. Semua informasi ini tersedia untuk banyak individu internal.

Penyerang tahu ini, dan ingin informasi ini untuk mereka sendiri. Ini menempatkan target raksasa pada infrastruktur internal perusahaan Anda jika Anda salah satu dari toko-toko ini. Dan sebagaimana adanya, proses pengembangan Anda menjadi tanggung jawab keamanan. Jika perusahaan Anda cukup besar, dan basis kode Anda cukup terdistribusi, Anda bahkan bisa menjadi target untuk upaya infiltrasi manusia. Pada titik ini teknik Charlie Miller: menyuap pengembang dengan cukup uang dan dia akan menulis Anda bug yang tidak terdeteksi menjadi kemungkinan yang berbeda.

Itu tidak berarti tidak masuk ke produk OSS dengan cara yang sama. Itu hanya berarti Anda memiliki satu set data, kemudian ketika dirilis, dapat mengekspos kelemahan dalam basis instalasi Anda. Menjaga kerahasiaannya telah menciptakan utang kode terhadap sistem terpasang pelanggan Anda yang tidak dapat Anda bayar segera.

13
Ori

Anda akan ingin melihat makalah ini:

Hasilnya adalah terbuka atau tertutup adalah setara, tergantung pada seberapa banyak pengujian dilakukan pada mereka. Dan dengan "menguji", saya tidak bermaksud seperti apa "penguji" drone korporat rata-rata Anda, tetapi lebih seperti pengalaman di lapangan.

3
Bruce Ediger

Mari kita jujur ​​di sini, ketika seseorang mengklaim open source lebih aman daripada open source, mereka menggeneralisasi apa yang terjadi hari ini di sistem operasi server/desktop, seperti Linux (open source) versus Mac/Windows (proprietary, closed source).

Mengapa malware lebih cenderung mempengaruhi yang terakhir dan bukan yang pertama? Karena beberapa alasan, yang menurut saya yang paling penting adalah yang pertama (dipinjam dari jawaban lain untuk pertanyaan yang ditandai sebagai rangkap satu ini ):

  1. Perangkat lunak yang diinstal oleh pengguna dalam kasus distribusi Linux (atau OS open source lainnya), biasanya dikemas oleh organisasi terpusat (yaitu di kasus Ubuntu, ini dilakukan oleh Canonical, dan dihosting olehnya), yang meng-host binari yang dikompilasi dari sumber yang dikuratori/dipantau oleh komunitas open source. Itu berarti bahwa kemungkinan pengguna menginstal perangkat lunak yang terinfeksi, atau kemungkinan komunitas opensource menerima perubahan kode berbahaya, jauh lebih rendah daripada dalam kasus Mac/Windows, di mana pengguna biasanya menginstal perangkat lunak dari banyak tempat berbeda di web , atau dari berbagai vendor dari AppStores. Ada juga risiko bahwa server organisasi (mis. Canonical) diretas, tetapi risiko ini kecil karena organisasi ini mempekerjakan pakar TI terkemuka untuk menjalankan server mereka.
  2. Linux (atau OS opensource lainnya) jumlah pengguna jauh lebih rendah daripada pengguna Windows/Mac , sehingga pembuat malware lebih suka untuk tidak menargetkan mereka (sebagai manfaatnya)/rasio biaya lebih rendah dalam hal ini).
  3. Linux, karena hanya sebuah kernel, hadir dalam berbagai distribusi yang dapat Anda pilih , sehingga pembuat malware perlu menghabiskan upaya yang lebih besar untuk membuat kode berbahaya mereka kompatibel dengan banyak dari mereka (sehingga rasio manfaat/biaya lebih rendah dalam kasus ini).
  4. Sumber Linux (atau OS opensource lainnya) terbuka untuk dilihat/dimodifikasi oleh semua orang. Itu berarti bahwa ketika kerentanan keamanan ditemukan, siapa pun dapat menulis perbaikan untuk itu (tidak ada vendor lock-in, Anda tidak terikat dengan organisasi tertentu yang perlu Anda tunggu, untuk mengembangkan perbaikan), jadi secara teori patch keamanan terjadi lebih cepat daripada dalam kasus perangkat lunak berpemilik. (Namun, dalam praktiknya, biasanya tidak ada perbedaan, karena perusahaan yang menjalankan platform berpemilik seperti Windows dan MacOS, adalah perusahaan besar yang kebetulan cukup kompeten.)
0
knocte

Artikel OpenSource.com Jim Fruchterman " Apakah perangkat lunak keamanan sumber terbuka Anda kurang aman? " memberikan analogi yang sangat baik tentang bagaimana open source, meskipun penyerang mengetahui cara kerjanya, membuat perangkat lunak lebih aman bagi pengguna akhir :

Pikirkan enkripsi sebagai kombinasi terkunci yang aman untuk data Anda. Anda mungkin satu-satunya yang memiliki kombinasi, atau Anda dapat mempercayakannya untuk memilih beberapa rekan dekat. Tujuan brankas adalah untuk mencegah orang yang tidak berwenang mendapatkan akses ke kontennya. Mereka mungkin pencuri yang mencoba mencuri informasi bisnis yang berharga, karyawan yang mencoba mempelajari informasi gaji rahasia tentang rekan-rekan mereka, atau penipu yang ingin mendapatkan informasi rahasia untuk melakukan penipuan. Dalam semua kasus, Anda ingin brankas menjaga barang-barang Anda aman dan mengusir orang-orang yang tidak berwenang.

Sekarang katakanlah saya memilih brankas untuk barang-barang berharga saya. Apakah saya memilih Safe Number One yang diiklankan memiliki dinding baja setengah inci, pintu setebal inci, enam baut pengunci, dan diuji oleh agen independen untuk memastikan bahwa isinya akan bertahan selama dua jam dalam kebakaran? Atau, apakah saya memilih untuk Safe Number Two, sebuah brankas yang menurut vendor cukup dipercaya, karena detail desain brankas adalah rahasia dagang? Bisa jadi Safe Number Two terbuat dari kayu lapis dan lembaran logam tipis. Atau, bisa jadi itu lebih kuat dari Aman Nomor Satu, tetapi intinya saya tidak tahu.

Bayangkan Anda memiliki rencana terperinci dan spesifikasi Safe Number One, cukup untuk membuat salinan yang aman dari brankas itu jika Anda memiliki bahan dan alat yang tepat. Apakah itu membuat Safe Number One kurang aman? Tidak. Keamanan Safe Number One terletak pada dua perlindungan: kekuatan desain dan sulitnya menebak kombinasi saya. Memiliki rencana terperinci membantu saya, atau ahli yang aman, menentukan seberapa bagus desainnya. Ini membantu memastikan bahwa brankas tidak memiliki cacat desain atau kombinasi "pintu belakang" kedua selain kombinasi pilihan saya sendiri yang membuka brankas. Ingatlah bahwa desain aman yang baik memungkinkan pengguna untuk memilih kombinasi mereka sendiri secara acak. Mengetahui desain seharusnya sama sekali tidak membantu penyerang dalam menebak kombinasi acak dari brankas tertentu menggunakan desain itu.

0
Geremia