%­1­0­0­ ­G­ü­v­e­n­l­i­k­ ­G­a­r­a­n­t­i­s­i­ ­M­ü­m­k­ü­n­ ­m­ü­?­

%­1­0­0­ ­G­ü­v­e­n­l­i­k­ ­G­a­r­a­n­t­i­s­i­ ­M­ü­m­k­ü­n­ ­m­ü­?­



Hatasız yazılım yoktur değil mi? Bu yaygın bir düşünce olsa da, yazılımın günlük dijital hayatımızda hiçbir hatası olmadığı önermesine dayanan varsayımlarda bulunuyoruz. Kimlik sağlayıcıların (IDP’ler) kimlik doğrulamayı doğru yapacağına, işletim sistemlerinin kendi özelliklerine mükemmel şekilde uyacağına ve finansal işlemlerin her zaman amaçlanan şekilde gerçekleştirileceğine güveniyoruz. Daha da canlı bir şekilde, fiziksel güvenliğimiz için yazılıma güveniyoruz. uçaklara binmek, trafik şeritlerine uyumu veya öndeki araçla olan mesafemizi aktif olarak düzelten bir araba kullanmak veya belirli ameliyatlar geçirmek. Bunu mümkün kılan nedir? Ya da başka bir deyişle, neden kötü yazılımlar nedeniyle uçaklar gökten düşmüyor?

Yazılım kalite güvencesi, bilimsel ve mühendislik araçlarından ödünç alır. 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 tabi tutulamazken, yazılım projeleri incelemeye davet etmek için kaynak kodunu açabilir veya bazı kazanımlar elde etme umuduyla denetimler için kod gönderebilir. güvenlik garantileri.

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.

Test iyidir, ancak kapsamlı olduğunu iddia etmez. Hangi hataları bilmediğimizi bilmediğimiz için tüm hataları bulduğumuzun garantisi yok. 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, ileri teorem şunu kanıtlıyor: Z3 ve Coq bu teknolojinin daha geniş bir bağlamda uygulanmasını mümkün kılmıştır. Artık resmi olarak doğrulanmış Programlama dilleri, işletim sistemlerive derleyiciler özelliklerine göre çalışması %100 garantilidir. 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 depolama veya ağ oluşturma gibi kritik altyapıya dahil etmek için mühendislik ekipleriyle birlikte çalışan özel araştırma gruplarına sahiptir. Örnekler şunları içerir: AWS S3 ve EBS ve Azure Blok Zinciri. Ancak gerçekten ilginç olan gerçek şu ki, son birkaç yılda bulut sağlayıcıları denemek metalaştırmak müşterilerine satış yapmak için resmi doğrulama.

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ı, tek bir hesap için bile karmaşıktır ve bu karmaşıklık, dağıtılmış karar verme ve yönetişime sahip büyük bir kuruluşta önemli ö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) sağlayıcıları, bir süredir sanal bağlantı noktası kanalı (VPC) yapılandırmasını ve IAM rollerini analiz ederek ve ayrıcalıkların çok gevşek olduğu, güvenlik özelliklerinin düzgün kullanılmadığı ve verilerin açığa çıkabileceği durumları belirleyerek bu sorunu ele alıyor. internete. 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.

Resmi Doğrulamanın Bazı Kusurları

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, bütün bir bölüm “kamuya açık”ın ne anlama geldiğini tanımlayan ve uyarılarla dolu. 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ı üzerinden ağınıza yönlendirirseniz, analizci bunu bilemez. Bir hizmetin iki IAM rolüne erişimi varsa ve bunları gizli bir genel kovadan okumak ve herkese açık bir klasöre yazmak için birleştirebiliyorsa, 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.


Popular Articles

Latest Articles