it-swarm-tr.com

Açık Kaynak ve Kapalı Kaynak Sistemler

Anladığım kadarıyla açık kaynak sistemler 'nin kapalı kaynak sistemler ' den daha güvenli olduğuna inanılıyor.

Bu yaklaşımlardan birini veya bunların bir kombinasyonunu kullanmanın nedenleri arasında şunlar vardır: kültürel normlar, finansal, yasal konumlandırma, ulusal güvenlik, vb. - hepsi bir şekilde bu sistemin açık veya kapalı kaynağa sahip olmasının etkisi hakkında kültürün görüşü ile ilgilidir.

Temel endişelerden biri güvenlik. Açık kaynak sistemlerine karşı ortak bir konum, bir saldırganın biliniyorsa sistem içindeki zayıflığı kullanmasıdır. Kapalı kaynak sistemlerine karşı ortak bir konum, farkındalık eksikliğinin en iyi ihtimalle zayıf bir güvenlik önlemidir; yaygın olarak --- müstehcenlik yoluyla güvenlik olarak adlandırılır.

Soru, açık kaynak sistemlerinin güvenlik için ortalama olarak kapalı kaynak sistemlerine göre daha mı iyi? Mümkünse, lütfen analizi mümkün olduğunca çok sayıda sektörde belirtin, örneğin: yazılım , askeri , finansal piyasalar , vb.

Bu soru Haftanın BT Güvenlik Sorusu idi.
Daha fazla bilgi için 25 Mayıs 2012 blog girişi bölümünü okuyun veya kendinizinkini gönderin Haftanın Sorusu.

53
blunders

Açık kaynak yazılımın kapalı kaynak yazılımdan - veya tersi kavramdan - doğal olarak daha güvenli olduğu fikri saçmalıktır. Ve insanlar böyle bir şey söylediğinde genellikle sadece - FUD ve tartışmayı anlamlı bir şekilde ilerletmiyor.

Bu nedenle tartışmayı bir özgü projeyle sınırlandırmalısınız. Belirli bir kaşıntıyı çizen, belirli bir ekip tarafından oluşturulan ve iyi tanımlanmış bir hedef kitleye sahip bir yazılım parçası. Bu tür özel bir durumda, açık kaynak veya kapalı kaynağın projeye en iyi şekilde hizmet edip etmeyeceğini düşünmek mümkün olabilir.

Tüm "açık kaynak" ile tüm "kapalı kaynak" uygulamalarının karşılaştırılması sorunu, kişinin sadece lisansları karşılaştırması değildir. Uygulamada, açık kaynak gönüllü çabalar tarafından tercih edilir, ve kapalı kaynak en çok ticari çabalarda yaygındır. Yani aslında karşılaştırıyoruz:

  • Lisanslar.
  • Kaynak koduna erişim.
  • Çok farklı teşvik yapıları , eğlence için kar için.
  • Çok farklı yasal sorumluluk durumları.
  • Farklı ve çılgınca değişen takım boyutları ve takım becerileri.
  • vb.

Tüm bunların açık/kapalı kaynak olarak piyasaya sürülen tüm yazılımlarda güvenlik için nasıl çalıştığını yargılamaya çalışmak sadece bozuluyor. Gerçek değil, bir fikir beyanı haline gelir.

50
Jesper M

Bakımlı yazılım, olmayan yazılımdan daha güvenlidir. Bakım çabası, elbette, söz konusu yazılımın karmaşıklığına ve ona bakan insanların sayısına (ve becerisine) bağlıdır. Açık kaynak sistemlerinin daha güvenli olmasının ardındaki teori, kaynak koduna bakan "çok sayıda göz" olduğudur. Ancak bu büyük ölçüde sistemin popülerliğine bağlıdır.

Örneğin, 2008 yılında OpenSSL birkaç arabellek taşması içinde keşfedildi, bunların bazıları uzaktan kod yürütülmesine neden oldu. Bu böcekler birkaç yıldır kodda yatıyordu. Bu nedenle, OpenSSL açık kaynak olmasına rağmen ve önemli bir kullanıcı tabanına sahipti (sonuçta HTTPS web siteleri için kullanılan ana SSL kütüphanesi), kaynak kodu denetçilerinin sayısı ve becerisinin üstesinden gelmek için yeterli değildi ASN.1 kod çözmenin (hataların gizlendiği OpenSSL kısmı) ve OpenSSL kaynak kodunun (açıkçası bu şimdiye kadarki en okunabilir C kaynak kodu değildir) doğal olarak karmaşıklığı.

Kapalı kaynak sistemleri, ortalama olarak, Soru-Cevap yapacak çok daha az kişiye sahiptir. Bununla birlikte, birçok kapalı kaynak sistemi, işi tam zamanlı olarak yerine getirebilecek ücretli geliştiricilere ve test kullanıcılarına sahiptir. Bu, açık/kapalı sorunun gerçekte doğası gereği değildir; bazı şirketler açık kaynak sistemleri geliştirmek için insanları istihdam ederler ve muhtemelen bir kapalı kaynak yazılımı ücretsiz olarak üretebilirler (bu, Windows için "freewares" durumunda nispeten yaygındır). Bununla birlikte, ücretli test sahiplerine sahip olma ile kapalı kaynak arasında hala güçlü bir korelasyon vardır (korelasyon nedensellik anlamına gelmez, ancak bu korelasyonların da göz ardı edilmesi gerektiği anlamına gelmez).

Öte yandan, kapalı kaynak olması, elbette kötü olan güvenlik sorunlarını gizlemeyi kolaylaştırır.

Çok veya çok az güvenlik sorunu olan hem açık hem de kapalı kaynak sistemlerine örnek vardır. Açık kaynak * BSD işletim sistemleri ( FreeBSD , NetBSD ve OpenBSD ve diğer birkaç kişi) güvenlik konusunda çok iyi bir geçmişe sahiptir. Solaris de kapalı kaynaklı bir işletim sistemi olsa bile. Öte yandan, Windows bu konuda korkunç bir üne sahipti.

Özet: Bence, "açık kaynak güvenlik anlamına geliyor" fikri abartılıyor. Önemli olan, güvenlik konularının izlenmesi ve düzeltilmesine ayrılan zaman (ve beceri) ve bu çoğunlukla kaynağın açıklığı sorunuyla dikeydir. Ancak, sadece güvenli bir sistem istemiyorsunuz, aynı zamanda biliyorum güvenli olmasını da istiyorsun (hırsız olmamak önemlidir, ancak geceleri de uyumak için). Bu rol için, açık kaynak sistemlerinin küçük bir avantajı vardır: sistem açık kaynak olduğunda kasıtlı olarak gizlenmiş bir güvenlik deliği olmadığına ikna etmek daha kolaydır. Ancak güven, OpenBSD (bildiğim kadarıyla kırmızı bir ringa balığı olduğu ortaya çıktı, ancak, kavramsal olarak, kendim kodu kontrol sürece emin olamaz).

37
Thomas Pornin

Bence bu en kolay, en basit yöntem bir yazılım mühendisliğidir. Argüman genellikle şu şekildedir: açık kaynaklı yazılım daha güvenlidir çünkü kaynağı görebilirsiniz !

Çekirdeği yukarıdan aşağıya anlamak için yazılım mühendisliği bilgisine sahip misiniz? Tabii, böyle bir sürücüye bakabilirsiniz, ama gerçekten "ah evet, orada bir hata olmalı" diyecekler hakkında tam bir bilginiz var mı?

İlginç bir örnek: çok uzun zaman önce, beta çekirdeğinden birinde grsecurity'den (PaX yamaları) keşfedilen oldukça büyük bir şey olan bir boş işaretçi dereference hatası ortaya çıktı:

Bunun gibi bir kod parçasında tanıtıldı:

pointer = struct->otherptr;

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

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

ve pointer == NULL kontrolü derleyici tarafından optimize edildi - haklı olarak - bir boş işaretçi üyeler içeren bir yapıya verilemediğinden, işlevdeki işaretçinin boş olması hiç mantıklı değildir. Derleyici daha sonra geliştiricinin orada olması beklenen kontrolü kaldırır.

Ergo, buna göre, böyle büyük bir projenin kaynak kodu doğru görünebilir - ama aslında değil.

Sorun burada ihtiyaç duyulan bilgi düzeyidir. Sadece bu durumda (bu durumda) C, Assembly, belirli çekirdek alt sistemi, gelişmekte olan çekirdeklerle birlikte giden her şey ile değil, aynı zamanda derleyicinizin ne yaptığını da anlamanız gerekir.

Beni yanlış anlamayın, Linus'a yeterli gözlerle tüm hataların sığ olduğunu kabul ediyorum. Sorun beyinde gözlerin arkasındaki bilgidir. Ürününüzü geliştirmek için 30 vızıltı çocuğuna para ödüyorsanız, ancak açık kaynak projenizde sadece kod tabanı hakkında gerçek bir bilgiye sahip 5 kişi varsa, açıkça kapalı kaynak sürümünün nispeten daha az karmaşıklık varsayarak daha az hata olasılığı daha yüksektir. .

Açıkçası bu, Thomas Pornin'in tartıştığı gibi, zaman içindeki geçici projeler için de geçerlidir.

Güncelleme olmadığı gibi gcc'ye yapılan referansları kaldırmak için düzenlendi.

17
user2213

Kapalı ve açık kaynak arasında ayrım yapmak için en çok kullanılan tesislerin oldukça iyi tanımlandığını düşünüyorum. Bunların birçoğu burada listelenmiştir, her ikisinin de savunucuları vardır. Şaşırtıcı olmayan bir şekilde Kapalı Kaynak savunucuları onu satanlar. Açık Kaynak taraftarları da bunu güzel ve düzenli bir iş haline getirdiler (bir din olarak kabul eden birkaç kişinin ötesinde).

Profesyonel Açık Kaynak hareketi temelleri anlatıyor ve genel olarak güvenlik söz konusu olduğunda, tartışmaya en çok uyan noktalar şunlardır:

  1. Özelleştirme öncülü
  2. Lisans Yönetimi öncülü
  3. Açık Format öncül
  4. Many Eyes öncül
  5. Hızlı Onarım öncül

Bu yüzden bunu öncülle yıkmak, sanırım son ikisi burada başkaları tarafından oldukça özlü bir şekilde ele alındı, bu yüzden onları yalnız bırakacağım.

  1. Özelleştirme Öncesi
    Güvenlik için geçerli olduğu gibi, Özelleştirme Öncesi, yazılımı benimseyen şirketlere, bir lisansı güvence altına almak veya bir satıcıyı düzeltmeye ikna etmek zorunda kalmadan mevcut bir platforma ek güvenlik kontrolleri oluşturma yeteneği verir. onların bir şeyleri. Bir ürünün genel güvenliğini artırmak için bir boşluk bırakması veya bir boşluk görmesi gereken organizasyonları güçlendirir. SELinux mükemmel bir örnektir, bunu topluluğa geri verdiğiniz için NSA) teşekkür edebilirsiniz.

  2. Lisans Yönetim Önceliği
    Genellikle, F/OSS teknolojilerini kullanırsanız, üçüncü taraflarla teknoloji lisanslarını yönetmeniz gerekmediği (veya bunu yaparsanız çok daha azdır) ortaya çıkar ve bu tamamen Açık için geçerli olabilir. Kaynak ekosistemleri. Ancak birçok lisans (özellikle GPL) distribütörlere gereksinim getirir ve gerçek dünyadaki ortamların çoğu heterojen kapalı ve açık kaynak teknolojilerinin karışımlarıdır. Dolayısıyla, sonuçta yazılım harcamasını azaltsa da, kaynağın kullanılabilirliği, bazı şirketleri kaynağı serbest bırakma yükümlülüğü olduğunda kaynağı gizli tutarak OSS lisanslarını ihlal etmeye neden olabilir. Bu sonuçta lisans yönetimi öncülüğünü bir yükümlülük haline getirebilir (GPL gibi kapalı kaynak argümanı karşı lisanslar).

  3. Açık Format Öncesi
    Bu büyük ve aynı fikirde olduğum bir şey, bu yüzden vaaz vermekten kaçınacağım. 30 yıl sonra yazdığım bir dosyayı açabilmek istiyorum. Dosya, özel DRM denetimleri kullanılarak "korunuyorsa" ve erişmem gereken yazılım artık satılmıyorsa, kendim içeriğe erişme zorluğu önemli ölçüde artmıştır. Belgemi oluşturmak için kullanılan ve 30 yıl önceki açık kaynaklı bir üründe kullanılabilen bir biçim varsa, büyük olasılıkla bulabilir ve yasal olarak kullanabilirim. Bazı şirketler "Açık Formatlar" bant vagonuna Açık Kaynak bandwagonuna atlamadan atlıyorlar, bu yüzden bence bu argüman oldukça sağlam.

Listelediğim bir Altıncı öncül var, çünkü iyi tartışılmadı. Sıkışmaya eğilimliyim (paranoya olarak adlandırın.) Altıncı öncül, dünyadaki savunma departmanlarının kapağındaki tüy olduğunu düşünüyorum. Windows 2000 kaynağının bir kısmı sızdırıldığında dünyaya hecelendi.

Kapalı Kaynak Sorumluluk öncülü
Bir şirket onlarca yıl boyunca birden fazla sürümle kapalı kaynak kod kütüphanesi veya API üretiyorsa, küçük birey grupları üretim boyunca bu kaynağa erişebiliyordu. Bunlardan bazıları üçüncü taraf denetim grupları ve diğer şirketlere/hükümetlere geçen geliştiricilerdir. Bu kod yeterince statik ise, kapalı kaynak fayda öncülünde olduğu gibi uyumluluğu korumak için, bazı zayıflıklar yıllarca bildirilmeyebilir. Bu kapalı kaynağa erişimi olanlar, bu zayıflıkları incelemek için kod analiz araçları çalıştırma özgürlüğüne sahiptir, bu yazılım geliştirme mağazalarının hata depoları, istismarlara yol açabilecek "küçük" hatalarla doludur. Tüm bu bilgiler birçok dahili kişiye açıktır.

Saldırganlar bunu biliyor ve kendileri için bu bilgiyi istiyorlar. Bu mağazalardan biriyseniz, şirketinizin iç altyapısına dev bir hedef koyar. Ve dururken, geliştirme süreçleriniz bir güvenlik yükümlülüğü haline gelir. Şirketiniz yeterince büyükse ve kod tabanınız yeterince iyi dağıtılmışsa, insan sızma çabaları için bir hedef bile olabilirsiniz. Bu noktada Charlie Miller tekniği: bir geliştiriciye yeterli parayla rüşvet verin ve o size tespit edilemeyen bir hata yazacak ayrı bir olasılık haline gelir.

Bu, OSS ürünlerine de aynı şekilde girmediği anlamına gelmez. Bu sadece bir dizi veriye sahip olduğunuz anlamına gelir, daha sonra yayınlandığında kurulum tabanınızdaki zayıflıkları ortaya çıkarabilir. Özel tutmak, müşterilerinizin yüklediği sistemlere karşı hemen geri ödeyemeyeceğiniz bir kodlama borcu yarattı.

13
Ori

Bu makalelere bakmak isteyeceksiniz:

Sonuç olarak, açık veya kapalı, üzerinde ne kadar test yapıldığına bağlı olarak eşdeğerdir. "Test" ile ortalama kurumsal drone "test cihazınızın" ne yaptığını kastediyorum, daha çok saha deneyiminde olduğu gibi.

3
Bruce Ediger

Burada dürüst olalım, birisi açık kaynağın kapalı kaynaktan daha güvenli olduğunu iddia ettiğinde, bugün Linux (açık kaynak) ile Mac/Windows (tescilli, kapalı kaynak) gibi sunucu/masaüstü işletim sistemlerinde neler olduğu hakkında genelleme yapıyorlar.

Kötü amaçlı yazılımların neden ikincisini etkileme olasılığı daha yüksektir? En önemli olduğunu düşünüyorum çeşitli nedenlerden dolayı, ilk olanı ( ödünç - bu diğerinin kopyası olarak işaretlenmiş bir soruya bu diğer cevap ):

  1. Linux dağıtımı (veya başka bir açık kaynaklı işletim sistemi) durumunda kullanıcı tarafından yüklenen yazılım genellikle merkezi bir kuruluş tarafından paketlenir (örn. Ubuntu örneğinde, Canonical tarafından yapılır ve barındırılır), açık kaynak topluluğu tarafından küratörlük/izlenen kaynaklardan derlenen ikili dosyaları barındırır. Bu, kullanıcının virüslü yazılım yüklemesi veya açık kaynak topluluğunun kötü amaçlı kod değişikliklerini kabul etme olasılığının, kullanıcının genellikle web üzerindeki birçok farklı yerden yazılım yüklediği Mac/Windows örneğinden çok daha düşük olduğu anlamına gelir. veya AppStores'tan birçok farklı satıcıdan. Ayrıca kuruluşun sunucularının (ör. Kanonik) saldırıya uğraması riski de vardır, ancak bu risk küçüktür, çünkü bu kuruluş sunucularını çalıştırmak için birinci sınıf BT uzmanları kullanır.
  2. Linux (veya diğer açık kaynaklı işletim sistemleri) kullanıcı sayısı Windows/Mac kullanıcılarından çok daha düşüktür, bu nedenle kötü amaçlı yazılım yaratıcıları onları hedeflememeyi tercih eder (yarar olarak/maliyet oranı bu durumda daha düşüktür).
  3. Linux, sadece bir çekirdek olarak, seçim yapabileceğiniz çeşitli farklı dağıtımlarda gelir , bu nedenle kötü amaçlı yazılım yaratıcılarının kötü amaçlı kodlarını oluşturmak için daha fazla çaba sarf etmesi gerekir. birçoğu ile uyumlu olmalıdır (bu nedenle fayda/maliyet oranı bu durumda daha düşüktür).
  4. Linux (veya diğer açık kaynaklı işletim sistemleri) kaynakları herkesin görmesi/değiştirmesi için açıktır. Bu, bir güvenlik açığı bulunduğunda, herkes bunun için bir düzeltme yazabilir (satıcı kilidi yoktur, beklemek, düzeltmek için belirli bir kuruluşa bağlı değilsiniz), bu nedenle teoride güvenlik yamaları, tescilli yazılım durumlarından daha erken gerçekleşir. (Ancak, pratikte, genellikle hiçbir fark yoktur, çünkü Windows ve MacOS gibi tescilli platformlar işleten şirketler yeterince yetkin olan büyük şirketlerdir.)
0
knocte

Jim Fruchterman'ın OpenSource.com makalesi " Açık kaynaklı güvenlik yazılımınız daha az güvenli mi? " saldırganların nasıl çalıştığını bilmelerine rağmen, açık kaynak kodunun nasıl açık olduğu konusunda çok iyi bir benzetme sağlıyor. :

Şifrelemeyi verileriniz için güvenli, kilitli bir kombinasyon olarak düşünün. Kombinasyona sahip olan tek kişi siz olabilirsiniz veya birkaç yakın ortak seçmek için ona emanet edebilirsiniz. Bir kasanın amacı, yetkisiz kişilerin içeriğine erişmesini engellemektir. Değerli iş bilgilerini çalmaya çalışan hırsızlar, akranları hakkında gizli maaş bilgilerini öğrenmeye çalışan çalışanlar ya da bir aldatmaca gerçekleştirmek için gizli bilgi edinmek isteyen bir dolandırıcı olabilir. Her durumda, kasanın eşyalarınızı güvende tutmak ve yetkisiz kişileri dışarıda tutmak istersiniz.

Şimdi diyelim ki değerli eşyalarım için bir kasa seçiyorum. Yarım inçlik çelik duvarlara, inç kalınlığına sahip bir kapıya, altı kilitleme civatasına sahip olduğunun ve içeriğin bir yangında iki saat hayatta kalacağını doğrulamak için bağımsız bir ajans tarafından test edilen Güvenli Numara Bir'i mi seçerim? Yoksa, kasanın tasarım detayları bir ticari sır olduğu için satıcının güvendiğini söyleyen bir kasa olan Safe Number Two'yu mu seçerim? Güvenli olabilir İki numara kontrplak ve ince sacdan yapılmıştır. Ya da, Güvenli Bir Numara'dan daha güçlü olabilir, ama mesele şu ki hiçbir fikrim yok.

Doğru malzeme ve araçlara sahipseniz, güvenli kasanın tam bir kopyasını oluşturmak için yeterli olan Güvenli Bir Numara'nın ayrıntılı planlarına ve özelliklerine sahip olduğunuzu düşünün. Bu, Güvenli Bir Numarayı daha az güvenli hale getirir mi? Hayır. Safe Number One'ın güvenliği iki korumaya dayanıyor: tasarımın gücü ve kombinasyonumu tahmin etmenin zorluğu. Ayrıntılı planlara sahip olmak bana veya güvenli uzmanlara tasarımın ne kadar iyi olduğunu belirlememde yardımcı olur. Kasanın tasarım kusurları veya kasayı açan kendi seçtiğim kombinasyon dışında ikinci bir "arka kapı" kombinasyonu bulunmamasına yardımcı olur. İyi bir güvenli tasarımın kullanıcının kendi kombinasyonlarını rastgele seçmesine izin verdiğini unutmayın. Tasarımı bilmek, bir saldırganın bu tasarımı kullanarak belirli bir kasanın rastgele kombinasyonunu tahmin etmesine yardımcı olmamalıdır.

0
Geremia