Yazılım kalite güvencesi, bilimsel ve mühendislik disiplinlerinden ödünç alır. Bilimdeki tekrarlanabilirliğe benzer şekilde, yazılım kalitesini sağlamanın ve geliştirmenin bir yolu, onu tanıtmak ve mümkün olduğu kadar çok insanı onu kırmaya teşvik etmektir.
Bir diğeri, mühendislikten kaynaklanan tasarım modellerini veya iyi mimari çerçeveleri kullanmaktır. Örneğin, her yazılım projesi onlarca yıldır inceleme altında olan Linux çekirdeği ile aynı inceleme düzeyine konulamazken, yazılım projeleri güvenliğin bir kısmını elde etme umuduyla Linux çekirdeğinden ödünç alınan kanıtlanmış tasarım modellerinden yararlanabilir. garantiler.
Ve elbette, testler var. Geliştirici veya özel bir ekip tarafından yapılan statik, dinamik veya gerçek zamanlı test, yazılım geliştirmenin önemli bir parçasıdır. Kritik yazılımlarda, test genellikle özel uzmanlığa sahip ayrı bir ekip tarafından yürütülen tamamen ayrı bir projedir.
Tüm bu yöntemler iyidir, ancak kapsamlı olduklarını iddia etmezler ve tarih, onların olmadığını göstermektedir. Hangi hataları bilmediğimizi bilmediğimiz için (yanlış negatifler gibi) tüm hataları bulduğumuza dair hiçbir garanti yoktur. Linux çekirdek hatalarının %99’unu zaten orada mı bulduk? %50 mi? %10 mu?
‘Mutlak’ İddia
Resmi yöntemlerin araştırma alanı, borsacınız veya sertifika yetkiliniz gibi belirli bir yazılım parçasında hiçbir hata olmadığından emin olmanızı sağlamanın yollarını arıyor. Temel fikir, yazılımı her şeyin iyi tanımlandığı matematiğe çevirmek ve ardından yazılımın hatasız çalıştığına dair gerçek bir kanıt oluşturmaktır. Bu şekilde, yazılımınızın hatasız olduğundan emin olabilirsiniz, aynı şekilde her sayının asal sayıların çarpımına ayrıştırılabileceğinden emin olabilirsiniz. (Bir hatanın ne olduğunu tanımlamadığımı unutmayın. Daha sonra göreceğimiz gibi, bu bir sorun teşkil edecektir.)
Resmi yöntem teknikleri, kritik yazılımlar için uzun süredir kullanılmaktadır, ancak bunlar son derece bilgi işlem ve emek yoğundu ve bu nedenle, yalnızca çip belleniminin sınırlı bir parçası veya bir kimlik doğrulama protokolü gibi küçük yazılım parçalarına uygulandı. Son yıllarda, Z3 ve Coq gibi gelişmiş teorem kanıtlayıcılar, bu teknolojinin daha geniş bir bağlamda uygulanmasını mümkün kıldı. Artık, özelliklerine göre çalışması %100 garantili olan, resmi olarak doğrulanmış programlama dilleri, işletim sistemleri ve derleyiciler var. Bu teknolojileri uygulamak, hâlâ hem gelişmiş uzmanlık hem de tonlarca bilgi işlem gücü gerektiriyor, bu da onları çoğu kuruluş için aşırı derecede pahalı hale getiriyor.
Büyük bulut sağlayıcıları, yüksek düzeyde güvenlik güvencesine ulaşmak için temel yığınlarının resmi doğrulamasını gerçekleştiriyor. Amazon ve Microsoft, resmi doğrulama yöntemlerini AWS S3 ve EBS ve Azure Blok Zinciri gibi kritik altyapıya dahil etmek için mühendislik ekipleriyle birlikte çalışan özel araştırma gruplarına sahiptir. Ancak gerçekten ilginç olan gerçek şu ki, son birkaç yıldır bulut sağlayıcıları, müşterilerine satış yapmak için resmi doğrulamayı metalaştırmaya çalışıyor.
Yanlış Yapılandırmayı Kararlı Bir Şekilde Çözmek mi?
Geçen yıl AWS, müşterilerini uzun süredir rahatsız eden sorunları, yani ağ ve kimlik ve erişim yönetimi (IAM) hatalı yapılandırmalarını ele almak için resmi doğrulamadan yararlanan iki özellik yayınladı. Ağ erişimi ve IAM yapılandırmaları karmaşıktır ve bu karmaşıklık, dağıtılmış karar verme ve yönetişime sahip büyük bir kuruluşta büyük ölçüde artar. AWS, müşterilerine “S3 klasörleri İnternet’e maruz kalmamalı” veya “EC2 bulut sunucularına giden İnternet trafiği bir güvenlik duvarından geçmelidir” gibi basit kontroller vererek ve bunların olası her yapılandırma senaryosunda uygulanmasını garanti ederek bu sorunu giderir.
Açık S3 klasörleri gibi AWS’ye özgü sorunlar için bile yanlış yapılandırma sorununu ilk ele alan AWS değildir. Bulut güvenliği duruş yönetimi (CSPM) tedarikçileri, bir süredir bu sorunu ele alıyor, AWS sanal bağlantı noktası kanalı (VPC) yapılandırmasını ve IAM rollerini analiz ediyor ve ayrıcalıkların çok gevşek olduğu, güvenlik özelliklerinin düzgün kullanılmadığı ve verilerin değiştirilebileceği durumları belirliyor. internete maruz kaldı. Ee başka?
İşte tam burada garanti devreye giriyor. Bir CSPM çözümü, kötü olduğu bilinen veya iyi olduğu bilinen yanlış yapılandırmalar listesi oluşturarak, bazen ortamınızdan bağlam ekleyerek ve buna göre sonuçlar üreterek çalışır. Ağ ve IAM analizörleri, her olası IAM veya ağ talebini inceleyerek ve belirtiminize göre (“İnternet erişimi yok” gibi) istenmeyen erişime yol açmayacaklarını garanti ederek çalışır. Fark, yanlış negatiflerle ilgili garantilerdedir.
AWS, hiçbir şeyi gözden kaçırmadığını iddia etse de, CSPM sağlayıcıları, kataloglamak ve tespit etmek için her zaman yeni yanlış yapılandırmalar aradıklarını söylüyorlar; bu, bu yanlış yapılandırmaları daha önce tespit etmediklerini kabul etmek anlamına geliyor.
Hata Nedir?
Resmi doğrulama, bellek güvenliği sorunları gibi iyi tanımlanmış sorunları bulmak için harikadır. Bununla birlikte, mantıksal hatalar bulmaya çalışırken işler zorlaşır çünkü bunlar, kodun gerçekte ne yapması gerektiğini belirtmeyi gerektirir, bu da tam olarak kodun kendisinin yaptığı şeydir.
Birincisi, resmi doğrulama, iyi tanımlanmış hedeflerin belirlenmesini gerektirir. İnternete erişimi engellemek gibi bazı hedefler yeterince basit görünse de gerçekte öyle değildir. AWS IAM çözümleyici belgeleri, “genel”in ne anlama geldiğini tanımlayan eksiksiz bir bölüme sahiptir ve uyarılarla doludur. Sağladığı garantiler, ancak kodladığı matematiksel iddialar kadar iyidir.
Bir de kapsama sorunu var. AWS analizörleri yalnızca birkaç büyük AWS hizmetini kapsar. Trafiği bir giden bağlantı kanalı aracılığıyla ağınıza yönlendirirseniz veya gizli verileri genel bir klasöre yazmak için birleştirilebilen iki ayrı IAM rolüne bir hizmet erişimi verirseniz, analizci bunu bilemez. Bununla birlikte, hatalı yapılandırma sorununun bazı iyi tanımlanmış alt kümelerinde, resmi doğrulama her zamankinden daha güçlü garantiler sağlar.
Yukarıda belirtilen göreli avantaj sorusuna dönersek, aradaki fark, IAM ve ağ analizcisinin tespit edilen sorunlar listesinin kapsamlı olduğunu iddia etmesi, CSPM’nin ise listesinin bugün bilinen tüm hatalı yapılandırmaları kapsadığını iddia etmesidir. İşte anahtar soru: Umurunda mı?
Mutlak Garantileri Önemsemeli miyiz?
Aşağıdaki senaryoyu düşünün. Bir CSPM’ye sahipsiniz ve AWS ağına ve IAM analiz aracına bakın. İkisinin sonuçlarını karşılaştırdığınızda, tamamen aynı sorunları belirlediklerini anlıyorsunuz. Biraz çaba sarf ettikten sonra, o listedeki her sorunu çözersiniz. Yalnızca CSPM’nize güvenerek, şu anda iyi bir yerde olduğunuzu hissedebilir ve güvenlik kaynaklarını başka bir yere ayırabilirsiniz. Karışıma AWS analizcileri ekleyerek artık AWS garantisiyle iyi bir yerde olduğunuzu biliyorsunuz. Bunlar aynı sonuçlar mı?
Resmi doğrulama uyarısını ihmal etsek ve sorunların %100’ünü yakaladığını varsaysak bile, CSPM gibi tespite dayalı hizmetlere göre faydaları ölçmek, kendi güvenlik riski iştahına sahip her bir kuruluş için bir egzersiz olacaktır. Bazıları bu mutlak garantileri çığır açıcı bulurken, diğerleri muhtemelen mevcut kontrollere bağlı kalacaktır.
Bu sorular CSPM’ye özgü değildir. Bir örnek vermek gerekirse, aynı karşılaştırmalar SAST/DAST/IAST web uygulaması güvenlik test araçları ve resmi olarak doğrulanmış yazılımlar için yapılabilir.
Bireysel organizasyon seçimlerinden bağımsız olarak, bu yeni teknolojinin heyecan verici yan etkilerinden biri, güvenlik çözümlerinin yanlış negatif oranlarını ölçmeye başlamanın bağımsız bir yolu olacak, satıcıları daha iyi olmaya zorlayacak ve iyileştirmeleri gereken noktalarda onlara net kanıtlar sunacaktır. Bu başlı başına siber güvenlik endüstrisine muazzam bir katkıdır.