Ateşli bir siber güvenlik ortamında, yazılımların tasarım gereği güvenli olması yönünde büyüyen bir koro var. Nisan ayında, ABD Siber Güvenlik ve Altyapı Güvenliği Dairesi (CISA) ve Ulusal Güvenlik Dairesi (NSA), Avustralya, Kanada, Birleşik Krallık, Almanya, Hollanda ve Yeni Zelanda’nın siber güvenlik yetkilileriyle işbirliği yaparak yazılım üreticilerini desteklemeyi amaçlayan yönergeler “tasarım gereği güvenliği ve varsayılan olarak yerleştirmek”.
Bu yeni belgede ajanslar, yazılım üreticilerini tehdit modellemesini tasarım aşamasında devreye almaya çağırıyor. Bu yönergeler, ABD hükümetinin ürettikleri ürünleri güvence altına almak için yazılım üreticilerine sorumluluk getirecek yasa çıkaracağı haberlerini hemen takip ediyor.
Tüm yazılım geliştiriciler güvenli yazılım oluşturmak ister, peki bunu yapmak neden bu kadar zor, tasarım yoluyla etkili güvenlik neye benziyor ve onu yazılım geliştirme sürecine dahil etmek için nelerin değiştirilmesi gerekiyor?
Meydan okuma
Siber güvenlik ihlallerinin yaygınlığı, güvenli yazılım oluşturmaya çalışan geliştiricilerin karşılaştığı büyük zorluğun kanıtıdır. Ürünlerini hızlı bir şekilde piyasaya sürmek için çabalayan yazılım üreticileri, güvenlik konusunda kestirme yollara başvurmaya teşvik ediliyor. Güvenli yazılım tasarlamanın zorluğu, yazılım mimarisinin karmaşıklığı arttıkça ve ekonominin her sektörü yazılım tarafından dönüştürülürken daha da zorlaşıyor. son Beyaz Saray’ın satıcıları kötü yazılımlardan sorumlu tutma niyeti güvenlik, mevcut piyasa teşviklerini düzeltme girişimi olarak görülebilir.
Bu, özellikle giderek daha karmaşık hale gelen ve farklı yazılım parçalarının nasıl etkileşime gireceğini tahmin etmeyi zorlaştıran tedarik zincirlerinde geçerlidir. Geçen yıl Air France, KLM ve Nissan dahil işletmeleri etkileyen artan tedarik zinciri saldırılarında bu zorluğu gördük.
Tasarım ve Tehdit Modelleme ile Güvenlik
Çoğu yazılım güvenliği etkinliğinin geliştirme sürecinin sonunda odaklandığı durum hâlâ böyledir, ancak bu bazı sorunlar yaratır. İlk olarak, uygulama güvenliği test araçları aracılığıyla yazılım taraması, bir uygulamanın tasarımındaki daha karmaşık kusurları gözden kaçırabilir. Ayrıca, geliştirmeyi tamamladıktan sonra bir hatayı belirlediğinizde, düzeltme maliyetli ve zaman alıcı olabilir.
Tehdit modelleme süreci aracılığıyla kod yazılmadan önce güvenlik açıklarını belirlemek ve ele almak çok daha iyidir. Tehdit modellemeye yönelik bir dizi farklı yaklaşım vardır, ancak hepsinde temel olan, sistemin tasarımını işlevler arası bir ekip olarak analiz etmektir – geliştirme ve güvenlik ekipleri potansiyel güvenlik ve gizlilik sorunlarını belirlemek ve bunları çözmek için bir plan geliştirmek için bir araya gelir. onları hafiflet.
Şimdiye kadar, çok basit. Peki bu neden olmuyor? Görünüşe göre üç ana engel var: beceriler, sorumluluk ve pratiklik.
Tasarım Yoluyla Gömülü Güvenlik
Temel bir zorluk, birçok geliştiricinin işyerine güvenli yazılım oluşturmak için teknik bilgi olmadan ve tehdit modelleme konusunda çok az veya hiç deneyim olmadan girmesidir. Yatırım yapmanız gereken bir yazılım becerisidir ve öğrenmesi zaman alır. Geliştiricinin odak noktası, anlaşılır bir şekilde, bir tehdit aktörünün bu yeni işlevsellikte bir güvenlik açığını nasıl bulabileceği değil, geliştirmekte oldukları işlevselliktir.
Bu da bizi, tasarım aşamasında güvenlik sorumluluğunun nerede yattığına dair netlik eksikliği olan ikinci engele götürüyor, bu da pek çok işletmede tehdit modellemenin çatlaklardan geçebileceği anlamına geliyor. Temel rollerine rağmen, geliştirme ekibi genellikle güvenliği güvenlik ekibinin sorumluluğu olarak görür. Çoğu işletmede tehdit modelleme süreci ve güvenlik riskleri hakkındaki bilgilerin güvenlik ekibi tarafından tutulduğu düşünülürse, bu da tamamen anlaşılabilir bir durumdur. Mühendisler olmadan güvenli yazılım tasarlayamayacağınız gibi, güvenlik ekibinin tehdit aktörleri tarafından kullanılan gelişen saldırı vektörlerine ilişkin içgörüsü olmadan da güvenli yazılım oluşturamazsınız.
Bu iki ekip, yazılım geliştirme sürecinin en başında birlikte çalışana ve tehdit modelleme, ortak sorumluluk içeren bir topluluk uygulaması olarak yerleşene kadar, bu sorun çözülmeyecektir.
Üçüncü engel, nispeten yakın zamana kadar, tehdit modellemeye yönelik geleneksel yaklaşımların, büyük ölçekte yazılım geliştirirken pratik olmamasıdır. Binlerce uygulama oluşturan bir kuruluş için, beyaz tahtalı bir toplantı odasında bir grup olarak tehdit modellemeye yönelik geleneksel yaklaşım mümkün değildir. Ancak, bu sürecin otomasyonu artık bir gerçek. Bir geliştirici olarak artık sizin için ilgili tehditleri ve karşı önlemleri içeren bir tehdit modeli oluşturmak için otomasyonu kullanabilirsiniz.
Dünyanın önde gelen siber güvenlik kurumlarının sunduğu bu son kılavuz, tasarım gereği güvenliğin artık yalnızca en iyi uygulama olmadığı, yazılım geliştirmenin temel bir parçası haline gelmesi gerektiği konusunda bizi şüpheye düşürmemelidir. Bunu başarmayı mümkün kılmak için araçlar şu anda var, ancak bu, bir satır kod yazılmadan önce geliştirme ve güvenlik ekiplerinin yakın işbirliği içinde çalıştığı ortak bir çaba olmalıdır.