Bu Help Net Security röportajında NetworkRADIUS CEO’su Alan DeKok, açık kaynak araçlarının seçimi ve bakımında gerekli özenin gösterilmesi gerektiğini tartışıyor ve yazılım güvenliğini geliştirmek için açık kaynak topluluğuyla işbirliği yapmanın potansiyel risklerini ve faydalarını ortaya koyuyor.
Açık kaynak bağımlılıklarındaki güvenlik açıkları genel güvenliği nasıl etkiler?
Pek çok şirket, projeleri detaylı bir şekilde incelemeden açık kaynaklı yazılım kullanıyor. Fikir şu gibi görünüyor, eğer proje halka açıksa sorun olmaz, değil mi? Ancak OpenSSL’deki Heartbleed saldırısında da gördüğümüz gibi, gerçek şu ki, ilgili koda herkes bakabilse bile kimse hatayı yakalayamadı. Pek çok firma kodu indirdi, bir ürüne koydu ve hiçbir inceleme yapmadan kullandı.
Bu gibi durumlarda, gerekli özenin gösterilmemesi genel güvenliği etkiler; açık kaynak seçme kararını etkilemez.
İncelenmemiş açık kaynaklı araçlar kesinlikle sistem güvenliğini azaltabilir. Açık kaynağa dayalı ucuz ürünler (ağ cihazları, masaüstü yazılımları vb.) satan yüzlerce firma var. Bu ürünlerin çoğunda güvenlik sorunları olması muhtemeldir. Bu sorunların bulunamamasının nedeni kimsenin bakmamasıdır.
Açık kaynaklı yazılımın güvenliği, özellikle yüksek riskli ortamlarda, özel mülk yazılımla karşılaştırıldığında nasıldır?
Çoğu kapalı kaynak yazılım, kamuya açık olmayan şirketlerde dahili olarak kullanılır. Bu nedenle güvenlik sorunları daha az önemlidir. Tarih, halka açık internette kapalı kaynak yazılım kullanıldığında, açık kaynak yazılımlarda gördüğümüze benzer güvenlik sorunlarının bulunduğunu gösteriyor.
Riskin yüksek olduğu ortamlarda satıcılar genellikle kullandıkları yazılımı (tescilli olsun veya olmasın) denetler. Ancak CISCO ASA cihazlarında yaşanan son VPN sorunlarında görüldüğü gibi durum her zaman böyle değildir. Ulus-devlet saldırganları, yakalandıklarından bir yıl önce hükümetlerin özel ağlarına sızmanın bir yolunu test edip geliştirebildiler; bu da potansiyel olarak felaketle sonuçlanabilecek bir durumdu.
Tescilli olması, varsayılan olarak daha güvenli olduğu anlamına gelmez. Açık kaynaklı ürünlerin kalite ve güvenlik durumu büyük ölçüde farklılık gösterir. Kuruluşlar akıllıca seçim yaparsa, açık kaynaklı bir araç seçerken herhangi bir ek risk oluşmamalıdır.
Bir kuruluşta güvenli bir açık kaynak ortamını sürdürmek için en iyi uygulamalardan bazıları nelerdir?
İlk adım, diğer birçok kişinin kullandığı açık kaynaklı projeleri kullanmaktır. Yalnızca az sayıda insan tarafından kullanılan projelerden daha güvenli olma olasılıkları daha yüksektir.
İkinci adım, projeyi yürütenlerin güvenliği ciddiye aldıklarını doğrulamaktır. İyi süreçleri var mı? Taahhüt imzalıyorlar mı? Kaynak kodu tarayıcıları çalıştırıyorlar mı? Güvenlik sorunlarına hızlı ve özenle yanıt veriyorlar mı?
Bir diğer etkili strateji ise modern, istikrarlı bir işletim sistemini (Ubuntu, RedHat, FreeBSD, vb.) takip etmektir.
Son olarak, kuruluşunuzdaki bir kişinin tüm sistemleri en son yama setiyle güncel tutmaktan sorumlu olduğundan emin olmak istiyorsunuz.
Uyumluluk ve mevzuat gereklilikleri açık kaynaklı yazılımın seçimini ve kullanımını nasıl etkiler?
Finansman olmadan açık kaynaklı projelerin resmi sertifika alması zordur. Bu nedenle, düzenlemeye tabi sektörlerde yer alan ve bu sertifikalara ihtiyaç duyan şirketler genellikle açık kaynaklı çözümleri kullanamıyor.
Geri kalanı için, açık kaynak gerçekten “dünyayı yemiş.” Çoğu modern teknoloji şirketi açık kaynak araçları olmadan var olamaz veya çok farklı tekliflere sahip olur. Bu şirketlerin kullandıkları açık kaynaklı yazılımlara yönelik uyumluluk kontrollerinin maliyetini üstlenmeleri gerekiyor.
Tüm bu şirketler orijinal açık kaynak projesine katkıda bulunmak için birlikte çalışsalardı genel olarak daha iyi durumda olacaklardı. Ancak deneyimlerimize göre, kuruluşlar “bu benimdir, bedelini ödemek zorundasınız” şeklindeki ticari zihniyete düştüklerinde, topluluğa katkıda bulunmanın neden yararlı olduğunu benimsemeleri zorlaşır.
CISO’lar açık kaynak bileşenlerini altyapılarına entegre etmenin risklerini etkili bir şekilde nasıl değerlendirebilir ve yönetebilir?
Ana riskler, yasal/lisans uyumluluğunun yanı sıra harici yazılım bileşenlerinin kullanılmasından (veya kötüye kullanılmasından) kaynaklanan güvenlik riskleridir. CISO’ların, ürün ekiplerinin hangi açık kaynaklı projelerin kullanıldığını takip etmesini ve bu projelerin güncel olmasını sağlaması gerekir.
Sıklıkla konuşulmayan ilgili bir konu da, açık kaynak projesini “çatallama” riskidir; bu, birisinin orijinal projenin kaynak kodunun bir kopyasını oluşturması ve onu bağımsız olarak daha da geliştirmesi anlamına gelir. Çatallama konusundaki genel zihniyet şu: “Kaynağımız var, bu yüzden onu değiştirebiliriz!” Ancak birkaç yıllık özel değişikliklerden sonra, artık orijinal projenin farklı hatalara ve farklı özelliklere sahip özel bir çatalını çalıştırıyorsunuz. Bu durumda açık kaynaklı projenin daha yeni sürümlerinden yararlanmak neredeyse imkansızdır. Çatallı proje bir anlamda kendine özgü bir yazılım haline geldi ve yükseltmeleri zorlaştırdı.
Bunu FreeRADIUS’ta birçok kez gördük. Müşterilerimize her zaman çok az değişiklikle veya hiç değişiklik olmadan FreeRADIUS’un “temiz” sürümünü kullanmalarını tavsiye ettik. Bu şekilde yükseltme yapmak, sorunları düzeltmek, özellik eklemek vb. işlemler onlar için önemsizdir. Bu süreç, müşterilerimizin yıllar içinde önemli miktarda zaman ve emekten tasarruf etmesini sağladı ve bence açık kaynağı benimseyen herkesin takip etmesi gereken bir süreç.
Kuruluşlar, yazılımlarının güvenliğini artırmak için açık kaynak topluluğuyla etkili bir şekilde nasıl işbirliği yapabilir?
Kuruluşların açık kaynak topluluğuyla işbirliği yapması *gerektiğine* kuvvetle inanıyorum. Çok fazla kişi açık kaynaklı projeyi indirip kaçıyor. Kurumsal varlıkların katılımının bir yolu, hata düzeltmelerine ve küçük özelliklere katkıda bulunmaktır. Şirketin katılımının gizli tutulması gerekiyorsa bu, anonim e-posta hesapları aracılığıyla yapılabilir.
Şirketler aynı zamanda orijinal projenin iyileştirilmesine yardımcı olmak için güvenlik analizlerinin sonuçlarını da kullanmalıdır. Burada biraz kişisel çıkar söz konusu. Bir şirket, bu yamaları geri gönderip topluluğun bunları ücretsiz olarak sürdürmesini sağlamak varken, neden açık kaynaklı bir proje için özel yamaları sürdürmek için kaynaklarını kullansın ki?
Google, OSS-FUZZ projesiyle bu konuda iyi bir iş çıkarıyor. Birçok hata buldu ve onu kullanan çok sayıda açık kaynaklı projeye yardımcı oldu.
Açık kaynaklı projelere statik analiz konusunda yardımcı oldukları için Coverity de harika bir örnek. FreeRADIUS, Coverity ile taranan ilk açık kaynaklı projelerden biriydi ve hataların belirlenmesinde son derece yardımcı oldu.
Son 15 yılımı açık kaynak kullanmalarına, açık kaynak projelerine katkıda bulunmalarına ve interneti daha iyi hale getirmelerine yardımcı olmak için şirketlerle çalışarak geçirdim. Katılan herkesin, ürünlerini kullanan şirketlerle birlikte çalışan açık kaynak topluluğunun gücünü gösteren bu işbirliğinden faydalandığını düşünüyorum.
Okumalısınız: