Yönetişim ve Risk Yönetimi , BT Risk Yönetimi , Standartlar, Yönetmelikler ve Uyumluluk
Satıcıları Güvenli Olmayan Uygulamalardan Sorumlu Tutmak Güvenli Liman ve Şeffaflık Sorularını Güçlendiriyor
Micheal Novinson (Michael Novinson) •
2 Mart 2023
Ticari üreticileri güvenli olmayan yazılımlardan sorumlu tutmaya yönelik yeni bir federal strateji, ulaşılabilir bir güvenli liman politikası gerektiriyor ve sektör gözlemcilerine göre, yazılım üreticilerinin önemli güvenlik açığı bilgilerini ABD hükümetiyle paylaşması konusunda caydırıcı olabilir.
Ayrıca bakınız: İsteğe Bağlı Panel | Sıfır Güven Ayrıcalıklı Erişim: 6 Temel Kontrol
Biden yönetiminin Perşembe günü yayınlanan Ulusal Siber Güvenlik Stratejisi, güvenli geliştirme uygulamalarını teşvik etmek için yazılım ürünleri ve hizmetlerine yönelik sorumluluğun değiştirilmesi çağrısında bulunuyor. Sorumluluk, yazılım ürünlerini bir araya getiren ve bunları federal hükümete lisanslayan büyük şirketlere kaydırılacak şekilde tasarlanmıştır. Yeni yazılım ürünleri oluşturmak için yaygın olarak kullanılan açık kaynaklı uygulamaların geliştiricilerini etkilemeyecektir.
Üst düzey bir yönetim yetkilisine göre, “Bu sorumluluğu, son beş yılda herhangi bir fon almamış iki kişilik bir açık kaynaklı projeye devretmelerine izin veremeyiz.” “Bu bize istediğimiz sonucu vermeyecek.”
Yetkililer, yeni stratejiyi duyururken, sorumluluk değişikliğinin “uzun vadeli bir süreç” olacağını ve potansiyel olarak tam olarak uygulanmasının on yıl süreceğini söylediler.
Ancak siber güvenlik sektörü çalışanları, yazılım üreticilerine sorumluluk getiren yasanın çıkarılmasından, ürünlerinden birinin yüksek oranda istismar edilen bir güvenlik açığına sahip olması durumunda, onların ABD hükümetiyle bilgi paylaşma olasılıklarının çok daha düşük olacağından korkuyorlar (bkz.: Beyaz Saray, Biden’ın Ulusal Siber Güvenlik Stratejisini Açıkladı).
Proofpoint Siber Güvenlik Stratejisinden Sorumlu Başkan Yardımcısı Ryan Kalember, Information Security Media Group’a “Sorumluluk tehdidi her zaman şeffaflığı caydıracaktır” dedi. “Burada basit, doğrudan ve kolay bir uzlaşma olduğunu düşünmüyorum.”
Sağlam Bir Sorumluluk Kalkanı Oluşturma
Yönetim, daha sıkı yazılım geliştirme uygulamaları sunacağını, bunları yazılım geliştirme sürecinde uygulamak için satıcılarla çalışacağını ve ardından bu uygulamaları benimseyen şirketler için bir sorumluluk kalkanı oluşturmak için endüstri ve Kongre ile birlikte çalışacağını öngörüyor. Üst düzey yönetim yetkilisi, bu sürecin bir yıldan uzun süreceğini tahmin ediyor.
Veracode kurucusu ve Baş Teknoloji Sorumlusu Chris Wysopal, sorumluluk kalkanının bir şirketin olgunluğunu ve güvenlik duruşunu dikkate alması gerektiğinden, güvenli liman yasası için NIST Güvenli Yazılım Geliştirme Çerçevesinden yararlanmanın gerçekçi olmaktan çok ilham verici olduğunu söylüyor. Kalember, mevcut hiçbir kurumun NIST’e uygunluğu değerlendirmek veya bir güvenlik olayından sonra suçu atamak için iyi bir konumda olmadığını söylüyor.
Wysopal, ISMG’ye “Güvenli yazılım oluşturmanın ne anlama geldiği konusunda birkaç farklı seviyeye ihtiyacımız var” diyor. “SSDF iyi bir başlangıç noktası, ancak bence daha pratik ve daha basit olması gerekiyor.”
Wysopal, güvenli limanın hem yerleşik, yerleşik yazılım üreticileri için yüksek beklentiler belirlemesi hem de yeni girişimlerin rekabet etme ve yeni bir ürünle pazara hızlı bir şekilde girme becerilerini engellememesi gerektiğini söylüyor. Saldırganlar genel amaçlı yazılımlar aracılığıyla kritik hedefleri vurabileceklerinden, yalnızca kritik altyapı yazılımları yerine tüm yazılımlar için sorumluluk tesis edildiğini görmek istiyor.
Wysopal, “Sadece su arıtma tesisinde çalışan yazılıma odaklanmak yerine, makul bir düzeye ulaşmak için tabanı biraz yukarı kaldırma konusunda endişelenmemiz gerekiyor” diyor.
Güvenli Limanda Neler Aittir?
Aqua Security’nin yazılım tedarik zinciri güvenliğinden sorumlu pazara açılma yöneticisi Nurit Bielorai, yazılım geliştirme en iyi uygulamalarının son iki ila üç yıl içinde neredeyse tamamen kod güvenliğine odaklanmaktan, geliştirme süreçlerini ve altyapıyı geniş bir şekilde birleştirmeye doğru değiştiğini söylüyor. NIST SSDF, kuruluşların kodun ötesine bakmalarını ve yazılımlarının bütünlüğünü ve kaynağını dikkate almalarını sağladı.
“Kuruluşlar bulut hizmetlerini veya yazılımlarını daha az güvenli hale getirmek için bir bedel ödemeli. Ancak şu anda bu bedeli ödemiyorlar.”
– Proofpoint siber güvenlik stratejisinden sorumlu başkan yardımcısı Ryan Kalember
Güvenli limanın bir parçası olarak Bielorai, kuruluşların yazılım geliştirme sürecinin sonunda çıktının şirketin amaçladığı şey olduğunu doğrulaması gerektiğini söylüyor. Ayrıca, söz konusu bileşenlerin söz konusu kuruluş tarafından geliştirilmiş veya başka bir yerden alınmış olup olmadığına bakılmaksızın, firmaların yazılımlarındaki tüm bileşenlerin tam bir güvenlik geçmişini sağlamaları gerektiğini söylüyor.
Bielorai, ISMG’ye “Ürününüzün doğru güvenlik sürecinden geçtiğini görürsem, tonlarca güvenlik açığı olan bir üründense bu ürünü seçme olasılığım çok daha yüksek” diyor. “Yazılım tüketicisinin neyi tüketmek üzere olduklarını anlamalarına izin vermekle ilgili.”
Wysopal, NIST SSDF’ye evrensel bağlılığın gerçekçi olmadığını söylese de, temel uygulama güvenlik testinin ve açık kaynak riskinin yönetiminin herhangi bir güvenli limanın parçası olması gerektiğine inanıyor. Wysopal’a göre uygulamaların otomatik statik ve dinamik testi, arabellek taşmaları, uzaktan komut enjeksiyonu ve SQL enjeksiyonu gibi en sık kullanılan kusurları ortaya çıkarabilir.
Ayrıca, bir sorumluluk kalkanı arayan kuruluşların, yeni güvenlik açıkları bulunduğunda hızlı bir şekilde tepki verebilmeleri için hangi üçüncü taraf kitaplıklarını ve açık kaynaklı yazılım sürümlerini kullandıklarını anlamaları gerektiğini söylüyor. Neredeyse her ticari yazılım üreticisi bir dereceye kadar uygulama güvenliği testi yapar, ancak güvenlik söz konusu olduğunda müşteri tabanı azalan eski ürünler genellikle ihmal edilir.
Wysopal, “Herkes bir yerlerde bundan biraz yapıyor” diyor. “Fakat bu, belirli bir satıcının tüm ürünlerinde tutarlı bir şekilde yapılıyor mu? 10 yıllık bir ürün satın alan, para ödeyen ve kurulumunu yapan biri, yalnızca satıcı şöyle düşünüyor diye büyük bir riske atılmamalı: ‘ Oh, peki, onu 10 yıl önce güvence altına almadık. Şimdi güvence altına almaya çalışmak çok pahalı.'”
Üreticileri Sorumlu Kılmanın Alternatifleri
Proofpoint’ten Kalember, bilgi paylaşımına zarar vermeden ticari üreticiler için sorumluluk oluşturmanın bir yolunu bulma konusunda fazla iyimser olmasa da, pazar Fortinet, VMware ve Microsoft, büyük ölçekte istismar edilen güvenlik açıkları nedeniyle.
Kalember, “Kuruluşlar bulut hizmetlerini veya yazılımlarını daha az güvenli hale getirmenin bedelini ödemeli” diyor. “Ama şu anda bu bedeli ödemiyorlar. Bunu yapmaya teşvik edilene kadar, varsayılan olarak etkinleştirilen tartışmasız yararlı kontrollere sahip olmayacaksınız.”
Kalember, Biden yönetiminin, hiç kimsenin okumadığı bir son kullanıcı lisans sözleşmesi aracılığıyla satıcıları sorumluluktan feragat etmekten alıkoyma çabasını destekliyor. Ayrıca, yazılım üreticilerinin çok faktörlü kimlik doğrulama, kapalı federasyon özellikleri ve dosyaları barındırırken kötü amaçlı yazılımlara karşı temel kontroller gibi güçlü güvenlik özelliklerini varsayılan olarak uygulamak için ekonomik teşviklere sahip olması gerektiğini söylüyor.
Kalember, “İnternette olmanın ve dünyanın en büyük pazarına satış yapabilen bir yazılım şirketi olmanın bedeli olarak – biraz maliyet getirseler bile – tüm bunlar üzerinde anlaşabilmeliyiz” diyor. “ABD’de sahip olduğumuz pazar gücü aslında burada bir şeyler yapmak için kullanılabilir.”